Movable Type–based XUL sidebar
Ben Goodger [asks](http://www.bengoodger.com/software/mb/movabletype.html) if people could write a Firebird-savvy blog script to dump into the new “page-in-page bar” (which is currently only accessible via bookmark preferences).
I’m tempted, but don’t take that as saying I’ll do it just yet—I have a history of not finishing personal projects! Well the UI mocked up by Ben here is quite easy to do, I have a XUL version of that more-or-less ready to go, in terms of what goes where, except for keywords and HTML editing buttons. (Don’t say things like that, I haven’t done the extended formatting toolbar yet, but that should just be matter of collapsing the toolbar…)
I’m leaving it for the night though, the editor isn’t working. editorElement.editorShell is undefined, which I thought it shouldn’t be. And I’ve tried calling *netscape.security.PrivilegeManager.enablePrivilege(”UniversalXPConnect”)* just in case that might be an issue. Nearly midnight here, so time to leave that for another day.
From specific points in Ben’s post:
* the design (white background, image, etc.) should be easy (CSS), but not done yet.
* Flexing is done.
* Cookie saving not yet done.
* Entry body/extended entry/excerpt are mutually exclusive, using the “collapsed” attribute of XUL’s *vbox* tags. I don’t think this should interrupt any undo history, but need to check when I get the editor working.
* How to hide fields not specified by script parameters? On-the-fly editing of the XUL document by Perl? Let’s us set the correct MIME type also. But no script signing is really possible, not sure yet if we need extra XPConnect privileges for anything.
* No formatting toolbar.
* Can MovableType see the Accept header (I assume it can)—a relatively sane way of choosing which type of quick-blog window to send to the client.
Basically, none of this is rocket science, it just has to be implemented. And I’ve only done the easy bits. The question of how to send the information back to the server is still open. To write my own data stream, I’ll probably need access to XPCOM components, requiring extra XPConnect privileges. Time to see if I can mix HTML forms in with this, and submit one of those…
If the one feature which needed extra XPConnect privileges was the cookie handling, due to needing *@mozilla.org/cookie;1*, is it worth the annoyance of a popup dialog asking permission in exchange for this?
I would know a lot of the above questions already if I’d ever actually done a full project in XUL 
August 6th, 2003 at 6:32 am
You can just post the XUL form elements with an XMLHttpRequest. Of course it gets ugly from there on, since you get back a string of HTML that either has an error message buried in it, or has a URL in the body onload that you need to GET to finish saving the entry (to do the rebuild, after it’s saved, really).
August 7th, 2003 at 12:55 am
Ah cool, that sounds grand! A lot nicer than the current editor situation anyway
Sounds like the icky bit you’re referring to is to just go through the code of MovableType and work out exactly what the format of an error message would look like.
Sorta-psuedocode follows:
var myXMLHTTPRequest = new XMLHttpRequest();
myXMLHTTPRequest.open(”POST”, “http://www.lyranthe.org/mymovabletype/mt.cgi”, false);
myXMLHTTPRequest.send(myGeneratedPostData);
var errMsg = parseMTResponse(myXMLHTTPRequest.responseText);
if (errMsg) {
alertUser(errMsg);
}
August 7th, 2003 at 1:21 am
Hmm… the thing is, the “MetaWeblog API”:http://www.movabletype.org/docs/mtmanual_programmatic.html#xmlrpc%20api seems to have all the necessary bits. Means you don’t have to write a new interface for publishing, you can use existing XML-RPC code in Mozilla, and the general codebase (if not the integrated version) could possibly be reused with other systems. I can’t think of any features (of basic “new post” functionality) that can’t work through this API.
For detecting Mozilla, I think Gecko/DATE in the User-Agent should be sufficient. But I don’t think we should just offer a XUL version to people on demand - even Mozilla people might want a HTML window. It might be better to make the detection primarily work at the point where bookmarklets are generated? This could default to a XUL-based bookmarklet for Gecko-based systems.
May 11th, 2004 at 11:43 am
My respect! Very interesting site - a good resource for everybody! John