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