Off the Main Road

I first heard about Transfer when Sean Corfield presented Model-Glue and Reactor to my local CFUG (Portland CFUG at the time, now it's the Portland Adobe Developer User Group). He mentioned a promising new project called "Transfer" that he was just looking into. (Having a procedural background, I asked some pretty naive OOP questions in the Q&A) Since then, I've followed Transfer blog posts and webcasts, but I've just recently had reason to dig into it.

Constructing an XML Object map doesn't seem worth the effort involved until I experienced the pain of building all those objects manually for a sizable project. For the small projects I worked on prior to that (4 tables max), Coldfusion's native proceedural methods with the occasional service cfc was a much faster route. (Both in building and final performance). However, once I started working on much larger projects I started to understand why tools like Transfer are useful.

I appreciate that Mark Mandel kept the XML Object Map from being verbose, but here's a question: Why do all of these Coldfusion OOP tools use XML for configuration? I imagine it's easy to parse, and easy to read if you know what the valid format is SUPPOSED to be, and Eclipse allows for helper plugins.... yet, it's a stumbling block for many CF programmers. Why is that?

• Coldfusion does not report XML parcing problems well.
• XML can be case sensitive unlike CF.
• Requires a separate config file; cannot modify configuration programatically.
• The elements involved are already in either SQL or CF, why map it out again in XML?

I would think there would be a Coldfusion way of initilizing these frameworks. Either a config CFC (with built in error checking) or a struct. Yet, XML seems to be preferred.

In the case of ORMs, it would be really cool if a SQL script could be parced by a config CFC to build out the initial config which could then be modified as needed. (renaming columns, modifying relationships, etc.)

But since all of these frameworks were created by programmers much more experienced than I, I suspect these were considered but XML was chosen despite it's downsides. Frankly, it's not hard to manage once you get used to the specific syntax, I'm just thinking out loud.