[OS-webwork] Validation Framework (checked into Xwork)
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
Re: [OS-webwork] Validation Framework (checked into Xwork)
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
Re: [OS-webwork] Validation Framework (checked into Xwork)
Jason,
Why are you writing a new validation framework when FormProc has already
gone through these issues? Check out FormProc ( http://formproc.sf.net/
) and let me know if their is something missing which would be necessary
to make it fit WebWork developer needs.
Sincerely,
Anthony Eden
Jason Carreira wrote:
Don't have all of the answers there yet (glad to have help!), but what I
was thinking for i18n support was to change
message value=my message/
To
message key=message1My default message/message
Any thoughts on how to do parameterized messages? Maybe have:
message key=message1
default${0} is an invalid name/default
messageparam value=fooProperty/
/message
Don't know... There's definitely more to be done here.
-Original Message-
From: Hani Suleiman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 21, 2003 4:02 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Validation Framework (checked into Xwork)
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
---
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
RE: [OS-webwork] Validation Framework (checked into Xwork)
Well, I didn't know it existed, for one :-)
In looking at it, it seems like it does too much. It seems to combine
bean population with validation. I'm also not sure how I feel about the
whole validation with any scripting language and RE's, etc. I actually
really kind of hate things that bundle BSF and allow scripting like
that. It's like .Net to me... Yes, you can write in multiple languages,
but it doesn't seem like a good idea.
That said, my mind could be changed. I have some attachment to my code,
but not enough that I wouldn't dump it if something better was there and
did what I wanted.
Can you describe how this could plug in where I have mine in place? It
would be called as an Interceptor after the parameters have been set
(both static configuration parameters and runtime request parameters).
It needs to be able to find configuration files (your framework also
uses XML files, I believe) for the Action class which act as defaults,
and alias specific configuration files which add to the defaults. This
should be dynamic, i.e. I shouldn't have to register the configuration
files in some master configuration file.
So how good a fit is it?
Also, has anyone looked at commons validator
(http://jakarta.apache.org/commons/validator/index.html)? It doesn't
seem to have any docs... From looking at the JavaDoc, it looks ok, but
it looks like it takes a little too much code to do it (it should be
seamless).
Thoughts anyone?
-Original Message-
From: Anthony Eden [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 21, 2003 6:03 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Validation Framework (checked into Xwork)
Jason,
Why are you writing a new validation framework when FormProc
has already
gone through these issues? Check out FormProc (
http://formproc.sf.net/
) and let me know if their is something missing which would
be necessary
to make it fit WebWork developer needs.
Sincerely,
Anthony Eden
Jason Carreira wrote:
Don't have all of the answers there yet (glad to have
help!), but what
I was thinking for i18n support was to change
message value=my message/
To
message key=message1My default message/message
Any thoughts on how to do parameterized messages? Maybe have:
message key=message1
default${0} is an invalid name/default
messageparam value=fooProperty/
/message
Don't know... There's definitely more to be done here.
-Original Message-
From: Hani Suleiman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 21, 2003 4:02 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Validation Framework (checked into Xwork)
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
Re: [OS-webwork] Validation Framework (checked into Xwork)
Response inline...
Jason Carreira wrote:
Well, I didn't know it existed, for one :-)
No worries...FormProc has been discussed as an option for validation in
WebWork in the past, so I figured that you knew about it.
In looking at it, it seems like it does too much. It seems to combine
bean population with validation. I'm also not sure how I feel about the
whole validation with any scripting language and RE's, etc. I actually
really kind of hate things that bundle BSF and allow scripting like
that. It's like .Net to me... Yes, you can write in multiple languages,
but it doesn't seem like a good idea.
FormProc can do as much or as little as you like. If you only specify a
validator then the values will only be validated. If you want to use
FormProc to do type conversion then you can specify a type converter.
This goes the same for storing the data (in a bean, hash map, etc),
Regarding alternative methods for validation: I believe that it is up to
the developer using FormProc as to how they want to validate. The nice
thing about FormProc is that you can do what you want with it.
That said, my mind could be changed. I have some attachment to my code,
but not enough that I wouldn't dump it if something better was there and
did what I wanted.
Can you describe how this could plug in where I have mine in place? It
would be called as an Interceptor after the parameters have been set
(both static configuration parameters and runtime request parameters).
It needs to be able to find configuration files (your framework also
uses XML files, I believe) for the Action class which act as defaults,
and alias specific configuration files which add to the defaults. This
should be dynamic, i.e. I shouldn't have to register the configuration
files in some master configuration file.
The actual integration with WebWork would probably have to be done by
someone else as a.) I am not intimately familiar with WebWork, b.) I
don't have a lot of time to work on it. The main reason I suggested
FormProc was because it is mature and has already gone through issues
like i18n.
I don't think it would be exceptionally difficult to integrate FormProc
and WebWork though. Your interceptor would need to call the method:
process(FormData[] formData, Locale locale) throws Exception;
...which is in the Form class. You can see an example of extending the
Form class in the HttpForm class, which converts an HttpServletRequest
to an array of FormData objects. The configuration is completely
pluggable as well, by implementing the FormConfiguration interface. The
FormManager class then allows you to add named configurations which are
then retrieved when the Form by the same name is passed to the
FormManager.configure() method.
There was also talk of an abstraction for pluggable validation. Anyone
working on this yet?
So how good a fit is it?
Also, has anyone looked at commons validator
(http://jakarta.apache.org/commons/validator/index.html)? It doesn't
seem to have any docs... From looking at the JavaDoc, it looks ok, but
it looks like it takes a little too much code to do it (it should be
seamless).
Thoughts anyone?
My thoughts are pretty clear at this point - unless you are going to do
form validation in a vastly different fashion then you may as well take
advantage of FormProc's maturity.
Sincerely,
Anthony Eden
-Original Message-
From: Anthony Eden [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 21, 2003 6:03 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Validation Framework (checked into Xwork)
Jason,
Why are you writing a new validation framework when FormProc
has already
gone through these issues? Check out FormProc (
http://formproc.sf.net/
) and let me know if their is something missing which would
be necessary
to make it fit WebWork developer needs.
Sincerely,
Anthony Eden
Jason Carreira wrote:
Don't have all of the answers there yet (glad to have
help!), but what
I was thinking for i18n support was to change
message value=my message/
To
message key=message1My default message/message
Any thoughts on how to do parameterized messages? Maybe have:
message key=message1
default${0} is an invalid name/default
messageparam value=fooProperty/
/message
Don't know... There's definitely more to be done here.
-Original Message-
From: Hani Suleiman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 21, 2003 4:02 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Validation Framework (checked into Xwork)
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
RE: [OS-webwork] Validation Framework (checked into Xwork)
FormProc can do as much or as little as you like. If you only specify a validator then the values will only be validated. If you want to use FormProc to do type conversion then you can specify a type converter. This goes the same for storing the data (in a bean, hash map, etc), Regarding alternative methods for validation: I believe that it is up to the developer using FormProc as to how they want to validate. The nice thing about FormProc is that you can do what you want with it. That's fair. As long as I don't have to use all of it. The actual integration with WebWork would probably have to be done by someone else as a.) I am not intimately familiar with WebWork, b.) I don't have a lot of time to work on it. The main reason I suggested FormProc was because it is mature and has already gone through issues like i18n. Yeah, no problem. I'm talking about me doing it, just trying to judge if it's a good fit and I should look into it more. I don't think it would be exceptionally difficult to integrate FormProc and WebWork though. Your interceptor would need to call the method: process(FormData[] formData, Locale locale) throws Exception; ...which is in the Form class. You can see an example of extending the Form class in the HttpForm class, which converts an HttpServletRequest to an array of FormData objects. So do Actions have to extend Form? That's a big drawback. Would it be possible to abstract that? Or just automatically wrap a bean? Right now what I've got is field validators that are given the name of the field to work on, and can use Ognl to get the value of the field (Ognl uses reflection under the covers to get it) and can use it in validation. The configuration is completely pluggable as well, by implementing the FormConfiguration interface. The FormManager class then allows you to add named configurations which are then retrieved when the Form by the same name is passed to the FormManager.configure() method. Ok, so this is where I could plug in the auto-finding configuration, or is that already built in? There was also talk of an abstraction for pluggable validation. Anyone working on this yet? Interceptors allow anything to be pluggable! :-) Seriously, I implemented this validation stuff as an Interceptor, and just about anything else like this which is orthogonal to the execution of an Action can be done this way, including plugging in any validation framework you wanted. Jason --- 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
