From cocoon-dev-return-33171-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Fri Nov 22 11:18:53 2002 Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 90000 invoked by uid 500); 22 Nov 2002 11:18:52 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 89989 invoked from network); 22 Nov 2002 11:18:51 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Bertrand Delacretaz Organization: codeconsult To: cocoon-dev@xml.apache.org Subject: Re: [RT] BEans And Forms Framework (BEAFF) Date: Fri, 22 Nov 2002 12:19:00 +0100 X-Mailer: KMail [version 1.3.1] References: <20021121090414.4B45523CD8@dj.codeconsult.ch> <20021122105352.GC5273@tokyo.dvs1.informatik.tu-darmstadt.de> In-Reply-To: <20021122105352.GC5273@tokyo.dvs1.informatik.tu-darmstadt.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20021122111900.E0C2523CD8@dj.codeconsult.ch> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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? 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: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org