Movable Type Developers Contest Results

Mere days after submitting it to the contest, I was devastated to discover a small but serious flaw in Builderoo. The flaw prevents text filters from appearing in the Console on systems where CGI scripts are executed by the web server without using their full paths. This is caused by a bug in Movable Type where plugins are not loaded when the MT::App is initialized with a relative path. In turn, the idea to initialize the MT::App with a relative path is lifted straight from Movable Type's own CGI scripts, so I didn't expect it to be a problem. It turns out that the MT CGI scripts work under these conditions only as a fluke, because the scripts are always in the MT root directory (so a relative path to the root is simply "./").

Due to the way MT 3 links to CGIs from its interface, third-party CGIs cannot be put in the root (and therefore must use relative paths to find the root under these circumstances), so I assume other developers that successfully built CGIs discovered and worked around this problem. Neither of my two testing environments produced this condition, so I didn't catch it until I did my BrainLog re-build. And since the Console is required for most of Builderoo's functionality, this little flaw could have easily disqualified my entry. (The latest version of Builderoo does not have this problem.) I can complain about MT 3.0D's eccentric behavior all I want, but it's my fault for not having tested in more environments, particularly common ones like my own web hosting provider.

While it is likely this teeny flaw kicked me out of the contest, I could not say whether I would have placed had I fixed it prior to submission. Throughout six weeks of fairly intense development, the question I most wanted an answer to was not, "Will this win a prize?" but rather, "Is this a good idea?" I believed I was solving several classes of important problems that had only been partially addressed in the past. Plugins that transformed sections of text in an entry were mostly implemented as template tag post-processors, which were wrought with inherent compatibility problems with text formatters. Some such plugins were popular enough that authors of popular text formatters explicitly coded them into the formatter to reduce the compatibility issues, but then only plugins explicitly made to be compatible could be used simultaneously. And any transformations that don't take place in the text filter do not show up during entry preview. Transforming entry text is such a useful thing to do that I felt the problem deserved a more robust solution.

Builderoo includes several sample text filters intended to demonstrate the potential of such a framework. SmartyFilter, RegexFilter, and RooBeautifier are all extensions of existing MT plugins (SmartyPants, MTRegex, and MTCodeBeautifier, respectively) that I believe were hampered by the limitations Builderoo tries to relieve. Verbatim is a "building block" text filter, one with a simple function that wouldn't necessarily be useful to apply to an entry entry by itself, but could be very useful for sections, or in combination with other simple filters. RooLaTeX, RooLilypond, and RooGraphviz are all heavy-duty plugins that generate pictures (mathematical formulae, musical score, and graphs, respectively) from textual short-hand you put directly into the entry, which is not feasable without a caching mechanism like Builderoo's, given the way MT normally uses text filters.

I'm hoping these ideas are compelling enough that others will come up with even more useful Builderoo-based plugins. RooSpell was the furthest thing from my mind until a couple of days ago, which convinces me that there's even better stuff I haven't thought of.

I could be wrong. Maybe nobody needs Builderoo. But I'm pretty sure I'm going to use it, and if you want to use it too, it's there.