Looking at the code Joe Rinehart provided in
this post on why it's a good idea to use XML configuration in Model-Glue, I think I would probably prefer the XML. (And that's saying something!)
But, I also think that the code as it stands could be better abstracted, so that the end-programmer wouldn't need to create all those objects. One strategy to abstract the complexity out of that could be to allow the programmer to just create a config object, and use that API to create other objects. I haven't thought through that idea completely, but it seems preferable to me on its face. I'm sure there are many other strategies as well.
In the comments to that post, Teddy R. Payne mentioned, "a generation script that auto generates your code and writes XML for you would seem like creating an abstraction on top of an abstraction. It seems that would introduce another layer of complexity."
I'm not convinced there is some arbitrary line where abstraction would increase complexity. In fact, as it is designed to reduce it, I'm not sure you'd be doing it right if it did increase complexity.
I would also point out that besides the abstractions we create
in Coldfusion, you might
very well see Coldfusion itself as an abstraction on top of Java, which in turn is an abstraction
of C/C++ (No more pointers!), which in turn is an
abstraction over assembler, which is an abstraction over machine code... and so on and on it goes.
Still further, we might want to abstract the idea of a queue (for instance) from handling it as an array
(or your preferred implementation). But that doesn't mean we wouldn't further abstract it as something else
to keep our domain consistent.
In any case, even though, yes you are adding code to do something you can do without code in
the case of a generation script, I see that as a valid approach to reducing complexity, especially if
you find XML to be generally more complex than scripts. Because once you've abstracted it, you no longer have
to think about it.
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
Because of all these posts I spent last night looking at MG example apps and ColdBox example apps. I will say this: because of the XML syntax, it was easy to follow what was going on in the application from one central file rather than opening multiple CFCs and pasting the application together in my head.
Posted by
Tony Petruzzi
on Jan 25, 2007 at 03:36 PM UTC - 6 hrs
Tony,
I can certainly see how that can be the case. One (relatively minor) thing I like about Ruby on Rails, for example, is you can tell by the URL immediately where to look and know what's going on.
Of course, my spaghetti apps that also violated DRY like a (insert analogy of choice here) are like that too. I'm not trying to compare them to an XML config file here, by any means - just that other things are required for it to have an easy-to-follow design (and, I would think with the smart people behind those frameworks that use XML config files, they are well designed).
Anyway, XML was really a minor point. I just wanted to argue that it could be possible, with better abstraction, to not have the PITA code Joe showed as an alternative to the XML (and also I wanted to respond to Teddy). I understand that some people prefer to use XML, and there are certainly valid reasons for doing so. I just like to take the other side (because XML adds complexity, for me) and show that it doesn't need to be the first place we look for a solution (of course, Joe already pointed out that it wasn't in this case!).
And along that line, I point out (can I add any more geometrical constructs in this sentance?) that I don't think it is some quality of XML that made the code easy to follow along - rather, that the guys who wrote and contributed to those frameworks were good designers.
Posted by
Sam
on Jan 25, 2007 at 04:22 PM UTC - 6 hrs
Boy, that was harder to do than I thought. Changed "Joe showed as the alternative" to "an alternative."
I misspoke the first time =)
Posted by
Sam
on Jan 25, 2007 at 04:29 PM UTC - 6 hrs
Exactly, it's the abstract grammar and well designed higher level language that should get the praise. XML is just the pointy brackets so that you can use build in validation and parsing functions rather than a custom syntax where you'd have to go write a real parser. No reason you couldn't create a custom textual language without all the noise and use that instead - it's just currently more of a PITA to design and evolve.
Posted by
Peter Bell
on Jan 25, 2007 at 05:05 PM UTC - 6 hrs
