If you
are 100% sure that your application will never need to change, then don't use a
config file at all. If you are 100% sure your application's architecture
will never change, use config file that is architecture dependant (if
appropriate). If you are anything but one of those two situations, you
need an architecture independant config file. The cost of doing it right
the first time is pretty darn small compared to having to do it again a year
from now because the app change and your shortcut won't work anymore.
Sean
Corfield and Hal Helms just traded a couple sizable posts on the FuseBox
forums regarding architecting with CFCs. Hal made the comment "rigor isn't something you can add in after the fact". While the ideas were generally shared between the posts,
that statement was the only direct quote of Hal's post in Sean's post.
When those two guys agree on
something (which isn't always a given), it's a VERY good idea listen to
what they have to say.
barneyb
---
Barney Boisvert, Senior Development
Engineer
AudienceCentral (formerly PIER System,
Inc.)
[EMAIL PROTECTED]
voice : 360.671.8708
x12
fax : 360.647.5351
www.audiencecentral.com
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Todd
Sent: Tuesday, March 25, 2003 1:14 PM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] MVCF at benorama.com
Ok, I guess if you're going to be working with java in the future, you should follow this. However, if you have no intentions of working with java... the need for speed and using a cfincluded file or wddx packet will work just fine.
Not -everyone- on this list is a java developer. I think people need to be reminded that now and then. Majority of everything I've seen talked on here is overkill if you have no intentions of porting this app to anything java related. I think everyone should keep that in mind when writing up future recommendations.
Refusing to be a sheep,
~Todd
At 01:07 PM 3/25/2003 -0800, you wrote:
Well, you could do an XSL Transform (or several) to get pretty much any XML file into something that could be WDDX deserialized. Some formats would be easier, some harder. This works really well when you have a very simple XML document. What about when you start wanting to read the file with Java directly, and WDDX isn't helpful at all though? If you made large sacrifices to allow WDDX to work (as would undoubtedly be the case with a complex document type), you've pretty much eliminated the benefit of using a language independant format to begin with.
I'd rather have a intuitive, concise config file that might mean a little work for the machine, versus one that's easy for a machine to parse but hard for me. I'm going to program the machine exactly one time, after that, all I'm going to do is be editing the file, so that's where the concern should be (especially for a framework situation). Couple that with the fact that programming the machine will undoubtedly be ugly any way you cut it (at least one XSL sheet, perhaps several, or a SAX/DOM parser routine), and the ugliness of the parsing pretty much becomes a moot point.
I'd say that's my $0.02, but I think it was probably more than that. Such is life.
cheers,
barneyb
