How would you handle i18n support, and parametrised messages?

Eg, if you wanted '${0} is an invalid name' as your message

Quoting Jason Carreira <[EMAIL PROTECTED]>:

> I checked a new validation framework into Xwork this morning that I got
> running last night. It's based on some ideas like runtime attributes and
> deployment descriptors. What it does (triggered by a
> ValidationInterceptor in the interceptor list for an action) is to load
> validation xml files for the action, in the following order, using
> classloader.getResourceAsStream():
> 
> 1) package/of/action/ActionName-validation.xml
> 2) package/of/action/alias-validation.xml
> 
> The xml file is parsed to create a Map of fieldname to List (containing
> one or more FieldValidator's). FieldValidator is an interface with the
> following signatures:
> 
>     void setMessage(String message);
> 
>     String getMessage();
> 
>     void validate(String propertyName, Action action) throws
> ValidationException;
> 
> All validators have a message property, and can have other properties
> (using the usual get/set naming) which will be set during configuration
> load time.
> 
> A validator.xml file looks like this:
> 
> <validators>
>     <field name="bar">
>         <validator type="required">
>             <message value="You must enter a value for bar."/>
>         </validator>
>         <validator type="int">
>             <param name="min" value="6"/>
>             <param name="max" value="10"/>
>             <message value="bar must be between 1 and 10."/>
>         </validator>
>     </field>
> </validators>
> 
> The params here are set using Ognl into the properties of the validator,
> so your validators can have whatever properties you need. Unlike
> Interceptors, which are (must be) stateless, Validators maintain the
> setup state in these properties and are cached after the initial load
> for an alias and reused. 
> 
> What this allows is for you to pull all of your validation out of your
> actions and reuse it. It should make Actions even more simple and
> straightforward. One other thing I've added (and this is all in the
> Xwork code) is a ValidationAware interface that Actions can implement to
> get the error messages set into them by the FieldValidator's. It's just
> the same method signatures from ActionSupport in WW. Otherwise, the
> FieldValidator just logs the message (if it extends
> FieldValidatorSupport, that is. If you want it to do something else,
> then implement FieldValidator).
> 
> Jason
> 
> 
> --
> Jason Carreira
> Technical Architect, Notiva Corp.
> phone:        585.240.2793
>   fax:        585.272.8118
> email:        [EMAIL PROTECTED]
> ---
> Notiva - optimizing trade relationships (tm)
>  
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> 
> 






-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Reply via email to