On 10/28/05, Matt Woodward <[EMAIL PROTECTED]> wrote: > > 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. > > If we were dealing with simple properties files I'd agree with you, > but we're not. In the case of Mach-II the XML file is a controller > file (as it is with numerous other frameworks even outside the CF > world), it isn't just simple name/value pairs, and using XML is > perfect for this purpose.
I've struggled with Mach-II. I find the config file terribly difficult to understand. I think there must be an easier way to do what Mach-II does with a config file. For example, why doesn't Mach-II just expose an API so that I can control the application with a .cfm file? I tried to do something like that with Fusebox. Fusebox 3's API isn't perfect, but I think it's a good start, especially given the tools we had. (The API consisted solely of public fields because we wanted it to work with CF 4.) Patrick -- Patrick McElhaney 704.560.9117 http://pmcelhaney.weblogs.us ---------------------------------------------------------- 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]
