curlgen using Scala Lift. Not. Or: XML considered harmful

The other day I was looking at a modest web framework's HtmlTag class and saw that it had a parent class: ComponentTag.  Fine; I'll subclass CurlTag from that parent. Not. The parent of ComponentTag was none other than XmlTag.  What made this almost funny is that this framework claims to spare you XML configuration pain.

Imagine if the authors of the first unix shell had required that scripts be written in COBOL.  COBOL was ubiquitous in business systems at that time.  And then just imagine some key, patented component, say, suid, somehow required that a hidden .conf  file parse correctly as COBOL ...

So here I find myself today re-visiting Lift, the web framework stalwartly bearing the Scala standard onto the field of software slaughter.

The author of the Scala 2.7.6 compatible Lift 1.0.1 web framework has admitted that to set a non-XML MIME Content-Type for a Lift app that you must manually re-code Boot.scala in your app.

Imagine.  Here is a framework where convention has triumphed over configuration.  Run a few maven tasks and all is installed and one more maven task and you are up and running.  So long as anything you output as web content has an HTTP response payload starting with

    ?xml version=
and then
   !DOCTYPE html

Even with the content type manually flipped in Boot.scala ( and that is not as obvious as the web posts and sanguine responses might lead you to believe) the XmlParser is invoked.  Oh vey. LiftRules.determineContentType must be called after this and before that ...

Perhaps when Martin Odersky wisely included Traits (from the Swiss Smalltalk team up the road from Laussane in Berne) it became debatable whether IoC containers would require implementaion using Dependency Injection.  But here I am, reaching into the bowels of Scala Lift, just to flip a MIME type and free myself of an enforced XML parse.  All this just to output a page of non-XML, non-HTML, non-XHTML and yet not mere text/plain web content.  When did all internet markup become trapped in angle brackets?

The GOF warned that the Hollywood Principle can make for software which is dificult to understand.  Imagine the starving actor.  Even in Kafka's world the anti-hero could petition to change, if not improve, his lot.  But we who might serve must now sit and wait in the hope that we might be called.  It has been said that IoC prevents spaghetti code at the price of macaroni code.  We were promised a platter with a few of these and a little of those.  All at the openly shared feast freely offered in the marketplace.  But not without risk of something indigestible in the stuffing.

There must be room for some measure of configuration in this mad rush to impress the CIO's with the trivial app that hints at a killer app.  RAILS is not a killer app.  Emulating RAILS is folly.  Software - and with no effort at all. Imagine.  Less effort than learning to unicycle.  But you won't touch that page without a Ruby programmer at your elbow.  Call it "peer-web-dev".  The Rubyist will be peering over your shoulder.

There are supposedly highly-principled reasons to prefer Lift to RAILS (though perhaps not to GRAILS) and, in fairness, perhaps Lift version 1.1.x will break this fond coupling with XML and XHTML.  But if Lift was to be an indication of the advantages of the Scala IT shop over the Java-only shop and C#-only shop then Scala has surely not found its "killer framework" in Lift.

My Kafka-esque nightmare: a revival of Hermes, from IBM, in the Aufhebung above and beyond the split of OS from application process - the messenge has almost arrived! - only we find that PlanK only installs in our wristwatch ant-gravity gadget if Maven was first installed ... POM-da-da-POM.