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
