Hi Christian, thanks for the input! >. . . > If the classes are only used to hold data, that could be done with a > DOM-like structure as well. Access could be done through jxpath. >. . .
You're right - I've been going for the java beans version with the idea of writing as much of the "important" code in java rather than scripting. I think both approaches are valid depending on one's preferences and environment. Of course if the DD model is good enough, both ways could be implemented if needed and depending on how much effort is put into this. >. . . > The DD could be used to generate javascript code that does the > validation. >. . . Ok if you're speaking of server-side javascript. Client-side javascript validations are too risky IMHO except for "pre-validations" that cause no harm to the business data if they don't run as expected or are hacked away by malicious users. I think validation could be added later on to BEAFF, a first version without it could be usable already, with some additional effort. >. . . > The DD should / could contain error messages as well. AFAIK xforms > does that already. Two types of error messages would be nice: a "short > error" and a "long error". >. . . How about a "text-key" property on fields, that is used to build i18n keys for the various messages? <field name="artist" text-key="musiccd.artist"/> Then, i18n messages use well-known prefixes suffixes: field.short-name.musiccd.artist = Artist field.long-name.musiccd.artist = Artist who sings or play on the CD field.tooltip musiccd.artist = Enter name of artist field.error.musiccd.artist.charset = Invalid characters in artist name This allows the DD to be focused on the actual data model while allowing many different messages. -Bertrand --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
