Peter Bell wrote, On 11/30/2006 2:19 PM:
I do agree about storing the data in a db which is how I handle ALL of my
metadata, but if I required everyone to load up a metabase just to use
LightBase, it'd never be used.
Of course, that would be silly =). But, it's not bad to consider as an
optional feature.
Given that I'm generating the files, it matters less to me whether they are
validated or not as I can validate metadata pre-generation, but I still like
the self validating benefits of the XML files with DTD enough to use them as
a best practice.
Now, when you say "self validating" ... Might you explain what all it
validates? I'm having trouble understanding what benefits that provides
above the programmatic variety.
I would agree that there are many projects where an XML file would be
overkill, but I don't feel on balance that they do any substantial harm and
for my use case (a framework) they are worth the extra trouble.
FWIW, my conversion came when I actually started USING the programmatic
config for LightWire. There were cases where I was getting funky errors and
a DTD (and a little additional CF validation) would have helped.
I'd love to try and use both versions, if you have them available, to
get a better understanding of what you mean. As I mentioned in the
post, lately all my configuration has been pretty simple - so I can
easily be overlooking something. But even where I need "categories" (as
I think Joe Rinehart called them, or perhaps "sections"), I still find
it easier to do something like:
db.dsn = "datasource";
db.username ="sam";
db.password = "password";
app.title_background_color = "##000069";
app.title_text_color = "white";
and so forth, as an example, rather than the equivalent XML. But, I
could see how that might get troublesome for beans without some care as
to the aesthetic structure of the file (I mean, don't be intertwining
arrays with different indexes) ... but I'd still prefer to look at, and
try to figure out what's going on in a file that looked like that (you
know, but still had say, the arrays indexed properly and in order in the
file) , as opposed to the XML.
You're right about the unit tests, but I'm not sure whether they replace the
benefits of the DTD or extend them. Will play with that and let you know!
You know, I thought about that as well. But, I don't know enough about
DTDs to make the observation. I'm fairly sure I could write a simple
one, based on my little experience and recollection, but I can't even
tell you what good they are, except to verify the syntax of your own
little DSL, as you mentioned.
Best Wishes,
Peter
On 11/30/06 2:24 PM, "Sammy Larbi" <[EMAIL PROTECTED]> wrote:
Peter (and all),
I'm probably a bit jaded, since I've spent the last 3 months on a Java
project, where XML config is the norm. But, as I see it, the benefits
you've mentioned for XML config files, while certainly valid, are not
something you can have only with XML. I've written up about it, and may
write in more detail later.
A lot of that is re-introducing the issue, for anyone who may not be
familiar (probably 1/2 of it)... If prodded, I may go more in depth on
why I don't think those benefits are exclusive to XML. I neglected to
mention any benefits I see exclusive to programmatic config files,
except the glaringly obvious "it's not XML, unless you're using CFML"
(which I didn't even mention outright.) Part of that is that I haven't
looked deep enough to find if there are any benefits exclusive to
programmatic config files.
Anyway, feedback is always welcomed and appreciated... it can help me
flush out my own ideas, and most importantly well help me (well, all of
us really) learn. But, I have to say, don't think I'm saying anything
new here:
http://www.codeodor.com/index.cfm/2006/11/30/Re-Should-you-use-XML-for-your-co
nfig-files/849
Peter Bell wrote, On 11/26/2006 2:48 PM:
Hi Sam,
Looking forward to your thoughts when you have the time to respond. Truth is
I don't like XML, so I'm looking for any excuse not to use it, but I also
want to be intellectually honest and highlight all of the benefits that XML
provides so hopefully I'll make the best decision for my use case rather
than just following my prejudices!
Best Wishes,
Peter
On 11/26/06 8:36 AM, "Sammy Larbi" <[EMAIL PROTECTED]> wrote:
Peter,
You make some good points. I plan to read those articles within the
next couple of weeks and write up a response if I'm still not completely
convinced. Its just that right now, because the semester is coming to a
close, I can't give it the time/attention a good response deserves. I
hope you'll excuse the delay =).
-Sam
Peter Bell wrote, On 11/25/2006 10:44 AM:
Hi Sam,
There are a few reasons. And what was going to be an email turned into a
posting!
Here are my latest thoughts on XML for configuration.
http://www.pbell.com/index.cfm/2006/11/25/Should-you-use-XML-for-your-confi>>>>
g
uration-files
Best Wishes,
Peter
On 11/25/06 9:07 AM, "Sammy Larbi" <[EMAIL PROTECTED]> wrote:
Jim,
Don't take this the wrong way, as it is a genuine question, but when I
read it, it sound sort of heckling. It is not meant to be, so forgive
me if it sounds that way to you.
When and why would I want to use this? In particular, why is it better
than say <cfinclude template="config.cfm"> where config.cfm sets all my
variables?
Thanks,
Sam
jim collins wrote, On 11/24/2006 6:39 PM:
What is config.cfc? Config.cfc allows application and session
variables in a ColdFusion application to be set from an XML file.
Config.cfc is available for download at
http://code.google.com/p/configcfc/
For subversion users the link is:
http://configcfc.googlecode.com/svn/trunk/
A big THANK YOU to Nic Tunney for his help, code review, and creating
the Application.cfc example. You rock dude.
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions
at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions
at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the instructions
at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the instructions
at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the instructions
at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
