Hi,
I
don't think that simple XML configuration files are overkill compared to
WDDX...
Configuration files should be easily "human" readable
and editable.
WDDX
was not designed to be "human" readable and editable, it is way of representing
and exchange complex data between web applications.
By
editing a WDDX manually, you'll take the risk to corrupt the WDDX
format.
As for
using cfscript for i18n, this is what we were using in our CF5-based
application.
The
problem is that anyone could break the application by inserting "bad" characters
in the cfscript variable definitions or by forgetting the ; at the end of the
line...
Usually i18n bundle files are not translated by
developers.
You
won't have any risks with .properties files (which are just plain .txt
files).
Benoit
Hediard
-----Message d'origine-----
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]De la part de Todd
Envoyé : mardi 25 mars 2003 22:14
À : [EMAIL PROTECTED]
Objet : 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
