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