On 10/28/05, Patrick McElhaney <[EMAIL PROTECTED]> wrote: > On 10/28/05, Joseph Flanigan <[EMAIL PROTECTED]> wrote: > > I did not mean to stir-up a discussion on Mach, I was using one > > aspect of Mach, XML, as something I think is wrong. > > I must jump to Joseph's defense here. I think ColdFusion framework > developers became infatuated with XML a few years ago -- starting with > XML fusedocs -- and it's gotten out of hand.
Agreed. Not only fusedocs -- which frankly were only ever used by a small % of FB developers, let alone CF developers in general -- but frameworks in general. XML is convenient when you need data that follows a specific structure that's more complex that name/value pairs. But it certainly is fairly standard to use XML to configure most frameworks since frameworks tend to be, well, fairly specific in their structure and thus a good match for XML. > I don't understand what was wrong with simpler text-based formats, > such as the java properties file and windows ini file. I thought that > a config file should only specify details; it should not implement > business logic. And I thought that's why config file formats tended to > be so constrained. The idea of an eXtensible format for config files > seems backwards to me. Some newer frameworks, such as Rails, focus on *convention* over configuration. For example, when Rails needs the model class file (think CFC) it doesn't need to look in a config file to see where things are located or what they are named -- it just assumes that the developer followed the convention and put it in the /app/models directory and that the name of the file is the same and the class name (well, classname with the .rb extension, but the point is the same). Same with the database -- it just assumes that the database table is lowercased, plural, and has underscores between camelcase, which is valid assumption about conventions typically practiced by many developers -- and of course any of the assumptions about convention can be overriden on a per-class or global level so you can use a *different* set of assumptions. Of course the config file for Rails is YAML... ;) <sidebar> As an aside, Fusebox *3* followed a similar pattern -- it assumed there was an fbx_switch.cfm file in the /yourapp/circuit directory that described the fuse(s) in the circuit. That made adding a new circuit as simple as dropping in the fbx_switch and calling the url. Fusebox *4* adds the (admittedly minimal) additional step of updating the configuration. If you've dealt with J2EE, you may have seen the pendulum swing from "Java objects alone aren't good -- we need enterprise interfaces/services" to "Argh J2EE requires me to build 3-5 files and keep in sync so I can do database access" to "Boy, code generation of all those files, or JDO, or POJOs are really good". <rant>Right now, CF is definitely leaning towards it's J2EE-like phase with the associated heft in implementations (e.g. the blind following of the DAO/Gateway/etc patterns), which I find especially ironic since one if it's big plusses has always been ease of use. Those patterns have their place, just as ActiveRecord and other (*enterprise*) patterns do -- but they are not *always* the right way to do things, anymore than you should blinding implent a Factory pattern any time you need an object.</rant> </sidebar> Back to the point -- XML is very useful for configuration, but it's not the only choice. But databases IMHO are an awful choice for application configuration as opposed to any of the text-oriented approaches such as properties/ini files, YAML, or XML. -- John Paul Ashenfelter CTO/Transitionpoint (blog) http://www.ashenfelter.com (email) [EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
