On 10/28/05, Joe Rinehart <[EMAIL PROTECTED]> wrote: > > The reason is that XML is primarily an exchange > > language. Because it is based on an abstract syntax notation, DTD, it > > is very easy to overload and mis-use as a data store such as in Mach. > > Yes, it stared as an exchange language, but the ability to build > structured, checked documents lends itself well to other applications > - this isn't a misuse. A "butter" knife does a good job spreading > jam; does that make it a misuse? > > I think others agree: Fusebox, Mach-II, Model-Glue, Struts, Spring, > ASP.NET, Coldspring, J2EE, heck, even Cisco routers now use XML for > configuration.
Yes, but the *really* cool developers use YAML :) You know, Rails developers... or OCaml or Python or Perl, which I think is the total list of platforms with YAML interpreters > > A web application can have 1000s of events, as such, a management > > system is a better choice to store events. > > An application-level event management system of any use needs to be > able to show these events in a structured format where application > flow can be "seen". XML provides a very nice structure for this. Not to mention the fact that <shouting>NOT EVERY SINGLE COLDFUSION APPLICATION INVOLVES A DATABASE</shouting>. Boy would that be fun -- please install MySQL/MS-SQL/DB2/Oracle/Postgres/etc so you can configure the application that doesn't need a database. I will, to save the replies about it, concede that you *could* use hsql (nee hypersonic) or sqlite or (horrors) MSDE/Jet as an embedded db for configuration. Property files with name/value pairs are sufficient for many types of configuration as well -- no database and no XML parser required. INI files in Windows and conf files in Unix have managed to power an application or two. But perhaps the most important point is the for *configuration* data, which is (relatively-speaking) static and typically *deployment*-oriented, text-based files of any sort (text/properties, XML, YAML, SGML, etc) allow you to easily manage the configuration data using version control and deployment tools. Having a config file for dev, test, and production that is versioned and managed in a SCC repository means that deployment doesn't consist of deleting/updating database vaules. Sure, you *could* drop the config table(s) in the db and then have all the SQL to create the right configuration, but that's a lot of complication for little benefit. Oh, and where do you store the DSN configuration information? So you're stuck with at least a one-line config file or a hardcoded dsn name in the code. That's smart. -- 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]
