Joe Rinehart, XML, and Why DSLs Should Be a Required Subject (!)
However, he also made some statements that weren’t . . .
He said:
When I started writing Model-Glue, I shared the view of many others where I just didn't see why XML should be necessary to use a framework. I mean, I already know ColdFusion, why not just script together the events, listeners, etc? Let the CFCs themselves be the framework.
I certainly know that experience as I’ve been through it myself and I now believe XML config files provide a good number of values for a wide range of use cases.
He then compared using scripting to an XML based approach and when looking at the benefits of XML he noted:
1. I could create my own syntax that was Model-Glue specific, expressing multiple lines of CFML script in a single tag.
2. I abstracted my application from the framework's API.
In fact, the first statement is a general benefit of a Domain Specific Language. Creating a method call does exactly the same thing. As for the second, all he has done is move the grammar of his configuration DSL from an API to XML. He could have done that equally well by creating a set of cfcs with method calls corresponding to his XML grammar that then call the underlying API (if for some reason there is a need for the two layers). Of course, if you change the API (in a way that isn’t backwards compatible) applications will break. Try changing the names of all of the tags in your XML grammar or requiring extra arguments to them and it’ll break in the same way. If you change the abstract grammar of your DSL, you’ll break your existing code – irrespective of whether your concrete grammar is expressed in XML, ColdFusion or UML.
None of this should be taken as supporting an in-language API style DSL over an XML DSL. Both concrete syntaxes have strengths and weaknesses that Fowler covers pretty well in his Language Workbenches and DSL pieces, but I do wish people would make the distinction between abstract grammar and concrete grammars and distinguish syntactical from fundamental issues more clearly.
Oh jeesh – I’m now officially a grammar nit for computer languages. How sad . . . .
Fact is I am NOT saying XML is a bad choice - I'm just saying that some of the reasons that Joe gave for it being a good choice are wrong. There are plenty of other good reasons to use XML. Also check out stuff like the spring 2.0 IDE project. No reason why you can't have IDE support for XML syntaxes.
I think Joe's experience of starting out not wanting to use XML as the API for a framework resonates with must of us, which is why I think the community should give Steve's new implementation a chance and why I am so excited about hearing his presentation on it next Thursday.
The two most salients point that Steve makes for moving to a CFC API is that an XML API necessitates redefining existing ColdFusion as well forcing devlopers to learn the tags, syntax and keywords of the API (Fusebox currently consists of 20 tags and over 100 attributes) and many of these tags exist elsewhere in ColdFusion with different attributes. Why are we reinventing the wheel when Frameworks are all about code-reuse and conventions?
As a bonus, Steve's proposed Fusebox implementation does not require any core files!
I am currently building my own blog, but you can be sure that I am going to post about this as soon as I get it ready (the url is webmusings.org).
I'm also looking forward to Steves talk, but there is a material misunderstanding that keeps coming up. If you want to have 20 "commands" in your language, developers will have to learn those 20 commands. Doesn't matter whether they are XML tags, CFC method signatures or different shapes in a UML diagram. If you have a grammar with 20 elements, irrespective of syntax (XML, ColdFusion, pretty pictures, whatever) developers still have to learn those 20 commands. Putting them into an API does NOT make them go away it just changes the set of characters you use to call them.
In additional, with XML, you get free validation against a schema and people are stopped from just hacking in their own ColdFusion which is not possible with an in-language DSL unless you write a pre-parser which introspects your CF scripts pre-runtime to validate and clean up the CF code you write.
Fusebox is a bit of a special case as it has a bunch of tags that correlate to CF tags and it tries to provide control flow and looping which goes to the old dictum that every DSL eventually just becomes a badly designed general purpose language, but it is still important to distinguish between differences in abstract and concrete syntaxes.
I just finished reading your post from yesterday with the same title except with Steve Nelson instead of Joe Rinehart. You're right, putting the commands into an API does not make them go away.
Also, I just read Jeff Houser's "Frameworks without XML" and noted Matt Woodward's and Joe Rinehart's comment 's stating that Fusebox is different than most other frameworks in that it has the application logic defined in XML while the "others" do not.
In honesty, the problem is not with learning new commands. We are developer's and we will always have to learn something - we rather enjoy it for some reason. Learning a framework is all about learning its conventions. However, just having a Model CFC, View CFC and Controller CFC and including the appropriate files sounds like a lot less overhead than having a bunch of core files that need versioning and maintenance. In fact (I am about to open another can of worms), It is a lot like Ruby on Rails.
I got to go before I get myself in trouble now...
I don't think it is THAT much like RoR (which has its own problems) as in Ruby there are much more sophisticated metaprogramming features. It really isn't possible to build RoR with similar syntactic sugar because of language features CF just doesn't provide.
Anyway, will be interesting to see what Steve is up to!
Plug away, it's well worth promoting!