Hi Arnaud, Um... I'm not sure what you mean by i18n process but anyways...
I must apologize because I think I must have said something to mislead you. My proposed changes would not cause Castor to *rely* on any external files. Rather, they would merely allow ValidationException to provide more information. That is, I was planning to add instance variables to ValidationException for the field name, error type, field value, value restriction, etc. So it would be up to the client code to catch the ValidationException and handle it in whatever way that they deem appropriate. It was at this point that I figured a lookup would occur with the field name and error type concatenated together as the key to the name-value pairings. How someone might implement the lookup is entirely up to them and is external to Castor. They could use a flat text file, Java resource bundle, etc. - Castor wouldn't care. The way I was planning to implement this was to go into every XML Schema Validator class and at the point that the ValidationException was thrown, set the new error type, field value and value restriction instance variables. This would mean making minor modifications to about 25 Validator classes. However, the only place that I am aware that I can reliably get the field name is in XMLFieldDescriptorImpl.validate() so I'm planning to make some changes there as well to set the field name in ValidationException. Arnaud, please let me know what you think about my approach. I'd also like to welcome anyone else's suggestions or comments or... support!! The changes that I'm planning to make are relatively easy but unfortunately very tedious. : ( Thanks, Joyce ; ) --- Arnaud Blandin <[EMAIL PROTECTED]> wrote: > Hi Joyce, > > Doing some clean-up of our error messages is > definitely on our to-do > list, it is a great idea to provide better messages. > However I am not sure of the i18n process, it will > make Castor rely on > external files and can introduce newbie problems > with the CLASSPATH or > whatever but since Castor seems to be more and more > use at a production > level, it could be good. > What I recommend is to use the Message class in > castor.util package to > begin your implementation, you can then submit your > changes to the list > so that we can archive it, I don't think i18n will > be a priority before > reaching 1.0 but if you can ease the process once we > get there it could > be great. > > Thanks for supporting the project, > > Arnaud > > -> -----Original Message----- > -> From: Joyce Wong [mailto:[EMAIL PROTECTED]] > -> Sent: Thursday, January 03, 2002 10:44 PM > -> To: [EMAIL PROTECTED] > -> Subject: [castor-dev] XML Schema Validation: > returning the field name > in the > -> exception > -> > -> Hello Castor Folks, > -> > -> Before I plunge in to make the changes that I'm > -> planning to make, I have 2 questions with regards > to > -> my proposal below... > -> > -> 1. Is anyone interested in these features? > -> 2. Has it already been done? Or is it currently > -> being done by someone already? > -> > -> I would like to add the following features to XML > -> Schema Validation (i.e. validate is called during > -> marshalling and unmarshalling I believe...): > -> . consistently return the field name in the > exception; > -> . create a mechanism to allow multilingual > support for > -> error messages; > -> . allow the Business to easily use their own > wording > -> of error messages on a per field basis instead of > the > -> default English messages > -> > -> >From my understanding of the current state of > the XML > -> Schema Validation code: > -> . the field name was being returned by some of > the > -> validation classes but not all of them; > -> . error messages were only available in English; > -> . developers would have to go into the Castor > code to > -> change the error message on a per validation type > -> basis (rather than a per field basis) if the > Business > -> required that the error message be phrased > differently > -> and this would create forward-compatibility > issues > -> with future Castor versions; > -> > -> In more detail, this is what I plan to do... > -> > -> The old hard-coded English error messages will > become > -> the error descriptions intended only for > developers. > -> The field name and the validation error type that > I > -> will define and provide in documentation (e.g. > -> mandatory, min value, max value, length, pattern, > -> etc.) is returned with each exception and > together > -> they form the "error key" to an external resource > -> bundle of user-friendly error messages. However > the > -> lookup is implemented, I believe that the field > name > -> and the error type are sufficient to uniquely > identify > -> every validation error message required by an > -> application. Furthermore, rather than only > -> providing an English error description, the error > key > -> is returned for an error message lookup and the > field > -> name, field value and value restriction are > available > -> for substitution into generic error messages if > -> desired. > -> > -> This example should explain what I mean by value > -> restriction, field value, etc. > -> > -> Example, "The field value of 92 is less than the > -> minimum allowable value of 100" where "92" is the > -> field value and "100" is the value restriction > -> > -> Not only does this change in the Schema > Validation > -> interface provide a means to have multilingual > support > -> but it also makes it much easier for the Suits to > -> create their own error message for every > validation > -> performed even to the field level. If the lookup > is > -> implemented with a resource bundle then one is > created > -> for every language supported. Business > requirements > -> to change the wording need only be made to the > lookup > -> rather than to the Castor validation code itself. > -> > -> Please let me know what y'all think... Should I > do > -> it? > -> > -> Thanks, > -> Joyce : ) > -> > -> > -> > ______________________________________________________ > -> Send your holiday cheer with > http://greetings.yahoo.ca > -> > -> > ----------------------------------------------------------- > -> If you wish to unsubscribe from this mailing, > send mail to > -> [EMAIL PROTECTED] with a subject of: > -> unsubscribe castor-dev > > ----------------------------------------------------------- > > If you wish to unsubscribe from this mailing, send > mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ______________________________________________________ Send your holiday cheer with http://greetings.yahoo.ca ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
