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
