Re: Customizing validation
Looks like you want some pre-condition check before the validation.
If and only if the pre-condition is true, the validation will be executed.
I did the same thing several years ago.
There are 2 solution I tried:
(A)Inherit all the struts2 bundled validators, add some pre-condition
check code,
if and only if the pre-condition is true, invoke the method of the
base class. The base class (struts2 bundled validators) will do the
left work.
BTW, the pre-condition should be passed into the validators via
param, so the validators will not include any business logic and
they can be reused.
And since your pre-condition is a session attribute, I think you can
check it's value by OGNL expression. I am not very sure for this. If
you can not access session attribute via OGNL, maybe you need a
[getCountry] method in your action class, so the OGNL can retrieve the
value.
You don't need reinvent the whole wheels, but extend the existed wheels.
Source code like:
public class XXXValidatorEx extends XXXValidator {
private String condition; // here is the pre-condition in OGNL
public getCondition(); // omitted
public setCondition(); // omitted
private boolean evaluateCondition(){
// omitted
// you can read the code of [ExpressionValidator] and
[FieldValidatorSupport], to learn how to evaluate an OGNL expression.
}
public void validate(Object object) {
boolean result = this.evaluateCondition();
if (result ) {
super.validate(object);
}
}
}
There are about one dozen bundled validators, and the source code of
the inherited validators will be almost 100% same (only except the
class name and the base class name).
This will be a little ugly, but we have no choice, because Java don't
support multi-inherit or interface-delegation.
My choice was, generating all these source codes via FreeMarker, so I
need maintenance only one template file, but not one dozen of class
source codes.
(B)The other solution is much lighter.
No need the enhance the validator class, but express your
pre-condition and your validation rule all by expression.
like:
validator type=expression
param name=expression(!pre-condition) or (check-rule)/param
/validator
This will be easy to do, but hard to use,
because you must translate all the validation rules into some OGNL expression
Anyway, I think the final and most beautiful solution should be,
adding some [pre-condition checking] into the Struts2 bundled
validators themselves.
But this is out of our control, hope the developers of Struts2 can here this.
2011/11/28 Jyothrilinga Rao jyoth...@gmail.com:
Thanks Li Ying,
I got some information from
http://today.java.net/pub/a/today/2006/01/19/webwork-validation.html?page=3#custom-validators
but I do not want to reinvent the wheel (basically avoid coding my
validation logic in java code). If I
could have my actionClass-validation.xml structured as
validators
*country name=USA
* !-- Field Validators for email field --
field name=email
field-validator type=required short-circuit=true
messageYou must enter a value for email./message
/field-validator
field-validator type=email short-circuit=true
messageNot a valid e-mail./message
/field-validator
/field
!-- Plain Validator 1 --
validator type=expression
param name=expressionemail.equals(email2)/param
messageEmail not the same as email2/message
/validator
*/country*
*country name=AUSTRIA
* !-- Field Validators for email2 field --
field name=email2
field-validator type=email
messageNot a valid e-mail2./message
/field-validator
/field
!-- Plain Validator 2 --
validator type=expression short-circuit=true
param name=expressionemail.startsWith('mark')/param
messageEmail does not start with mark/message
/validator
*/country*
/validators
I am looking for something like a wrapper on existing bundled validators.
Is it possible.
Regards,
JK.
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
Re: Customizing validation
If the goal is to execute validations based on arbitrary preconditions (I
missed the original req) the *easiest* thing to do might be to just
extend/usurp the existing validation interceptor to do that precondition
check.
d.
On Mon, Nov 28, 2011 at 7:58 PM, Li Ying liying.cn.2...@gmail.com wrote:
Looks like you want some pre-condition check before the validation.
If and only if the pre-condition is true, the validation will be executed.
I did the same thing several years ago.
There are 2 solution I tried:
(A)Inherit all the struts2 bundled validators, add some pre-condition
check code,
if and only if the pre-condition is true, invoke the method of the
base class. The base class (struts2 bundled validators) will do the
left work.
BTW, the pre-condition should be passed into the validators via
param, so the validators will not include any business logic and
they can be reused.
And since your pre-condition is a session attribute, I think you can
check it's value by OGNL expression. I am not very sure for this. If
you can not access session attribute via OGNL, maybe you need a
[getCountry] method in your action class, so the OGNL can retrieve the
value.
You don't need reinvent the whole wheels, but extend the existed wheels.
Source code like:
public class XXXValidatorEx extends XXXValidator {
private String condition; // here is the pre-condition in OGNL
public getCondition(); // omitted
public setCondition(); // omitted
private boolean evaluateCondition(){
// omitted
// you can read the code of [ExpressionValidator] and
[FieldValidatorSupport], to learn how to evaluate an OGNL expression.
}
public void validate(Object object) {
boolean result = this.evaluateCondition();
if (result ) {
super.validate(object);
}
}
}
There are about one dozen bundled validators, and the source code of
the inherited validators will be almost 100% same (only except the
class name and the base class name).
This will be a little ugly, but we have no choice, because Java don't
support multi-inherit or interface-delegation.
My choice was, generating all these source codes via FreeMarker, so I
need maintenance only one template file, but not one dozen of class
source codes.
(B)The other solution is much lighter.
No need the enhance the validator class, but express your
pre-condition and your validation rule all by expression.
like:
validator type=expression
param name=expression(!pre-condition) or (check-rule)/param
/validator
This will be easy to do, but hard to use,
because you must translate all the validation rules into some OGNL
expression
Anyway, I think the final and most beautiful solution should be,
adding some [pre-condition checking] into the Struts2 bundled
validators themselves.
But this is out of our control, hope the developers of Struts2 can here
this.
2011/11/28 Jyothrilinga Rao jyoth...@gmail.com:
Thanks Li Ying,
I got some information from
http://today.java.net/pub/a/today/2006/01/19/webwork-validation.html?page=3#custom-validators
but I do not want to reinvent the wheel (basically avoid coding my
validation logic in java code). If I
could have my actionClass-validation.xml structured as
validators
*country name=USA
* !-- Field Validators for email field --
field name=email
field-validator type=required short-circuit=true
messageYou must enter a value for email./message
/field-validator
field-validator type=email short-circuit=true
messageNot a valid e-mail./message
/field-validator
/field
!-- Plain Validator 1 --
validator type=expression
param name=expressionemail.equals(email2)/param
messageEmail not the same as email2/message
/validator
*/country*
*country name=AUSTRIA
* !-- Field Validators for email2 field --
field name=email2
field-validator type=email
messageNot a valid e-mail2./message
/field-validator
/field
!-- Plain Validator 2 --
validator type=expression short-circuit=true
param name=expressionemail.startsWith('mark')/param
messageEmail does not start with mark/message
/validator
*/country*
/validators
I am looking for something like a wrapper on existing bundled validators.
Is it possible.
Regards,
JK.
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
Re: Customizing validation
Changing the [validation interceptor] will switch on/off the all validations by one pre-condition. But what he need is: if and only if pre-condition-A is true, run validation-A; if and only if pre-condition-B is true, run validation-B; etc... So, I think the right way is, change the validators. 2011/11/29 Dave Newton davelnew...@gmail.com: If the goal is to execute validations based on arbitrary preconditions (I missed the original req) the *easiest* thing to do might be to just extend/usurp the existing validation interceptor to do that precondition check. d. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Customizing validation
If the need is across the application, then modifying the app-wide interceptor makes sense. App-wide rule-based validations require something higher-level than reworking existing validators, or writing new ones, to express something that is likely declarative in nature. Seems more like run this bunch of validations based on this condition--rather than simply look up validations based on the action name, lookup should be based on the condition(s). That's mechanism-level, not validate-level. d. On Nov 28, 2011 8:33 PM, Li Ying liying.cn.2...@gmail.com wrote: Changing the [validation interceptor] will switch on/off the all validations by one pre-condition. But what he need is: if and only if pre-condition-A is true, run validation-A; if and only if pre-condition-B is true, run validation-B; etc... So, I think the right way is, change the validators. 2011/11/29 Dave Newton davelnew...@gmail.com: If the goal is to execute validations based on arbitrary preconditions (I missed the original req) the *easiest* thing to do might be to just extend/usurp the existing validation interceptor to do that precondition check. d. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Customizing validation
Yes, of course you are right. But what you talking about sounds like to change S2 mechanism itself, which we can not do. As a S2 user but not a S2 developer, the simplest way is to write a new validator.. Of course, If the [pre-condition based validation] is a common request, I think it will be great if we post it to the S2 feature request list. 2011/11/29 Dave Newton davelnew...@gmail.com: If the need is across the application, then modifying the app-wide interceptor makes sense. App-wide rule-based validations require something higher-level than reworking existing validators, or writing new ones, to express something that is likely declarative in nature. Seems more like run this bunch of validations based on this condition--rather than simply look up validations based on the action name, lookup should be based on the condition(s). That's mechanism-level, not validate-level. d. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Customizing validation
The point of having extensible, open-ended interceptor and configuration mechanisms is precisely so we *can* extend it to meet application needs, without having to modify the framework itself. The framework provides the hooks, through interceptors and plugins, precisely for circumstances unforeseen by the original developers. Don't underestimate the malleability of Struts 2 at the user layer. d. On Nov 28, 2011 9:16 PM, Li Ying liying.cn.2...@gmail.com wrote: Yes, of course you are right. But what you talking about sounds like to change S2 mechanism itself, which we can not do. As a S2 user but not a S2 developer, the simplest way is to write a new validator.. Of course, If the [pre-condition based validation] is a common request, I think it will be great if we post it to the S2 feature request list. 2011/11/29 Dave Newton davelnew...@gmail.com: If the need is across the application, then modifying the app-wide interceptor makes sense. App-wide rule-based validations require something higher-level than reworking existing validators, or writing new ones, to express something that is likely declarative in nature. Seems more like run this bunch of validations based on this condition--rather than simply look up validations based on the action name, lookup should be based on the condition(s). That's mechanism-level, not validate-level. d. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Customizing validation
If your validate rules are fixed, only some parameters (integer/date format or something else) relies on the country setting, I suggest you implement it by retrieve the params via OGNL expression. The parameter for the Validators can be OGNL expression. These docs may help: http://struts.apache.org/2.x/docs/ognl.html http://commons.apache.org/ognl/language-guide.html If your validate rules are variable, you can implement your own Validator, and register it into struts2. Then, you can use it in the same way as you use the Bundled Validators. This documents may help: http://struts.apache.org/2.x/docs/validation.html#Validation-RegisteringValidators To learn how to write a validator, you can read the source code of Struts2/xWork, in package [com.opensymphony.xwork2.validator.validators] And you can find some samples via google. 2011/11/28 Jyothrilinga Rao jyoth...@gmail.com: Hi all, I am currently making use of the validator and able to work-out a example as discussed at http://struts.apache.org/2.x/docs/validation.html. My application has a concept of user's country which is stored in session. Now depending on the value of this attribute stored in session, I need to have different validation rules for the same form and action. I would still like to define validations outside of my action and JSP in a XML file. Is there something out of box provided which can fulfill my requirement ? or is there something I can extend on to fulfill this ? Thanks, JK. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Customizing validation
Thanks Li Ying,
I got some information from
http://today.java.net/pub/a/today/2006/01/19/webwork-validation.html?page=3#custom-validators
but I do not want to reinvent the wheel (basically avoid coding my
validation logic in java code). If I
could have my actionClass-validation.xml structured as
validators
*country name=USA
* !-- Field Validators for email field --
field name=email
field-validator type=required short-circuit=true
messageYou must enter a value for email./message
/field-validator
field-validator type=email short-circuit=true
messageNot a valid e-mail./message
/field-validator
/field
!-- Plain Validator 1 --
validator type=expression
param name=expressionemail.equals(email2)/param
messageEmail not the same as email2/message
/validator
*/country*
*country name=AUSTRIA
* !-- Field Validators for email2 field --
field name=email2
field-validator type=email
messageNot a valid e-mail2./message
/field-validator
/field
!-- Plain Validator 2 --
validator type=expression short-circuit=true
param name=expressionemail.startsWith('mark')/param
messageEmail does not start with mark/message
/validator
*/country*
/validators
I am looking for something like a wrapper on existing bundled validators.
Is it possible.
Regards,
JK.
On Sun, Nov 27, 2011 at 10:06 PM, Li Ying liying.cn.2...@gmail.com wrote:
If your validate rules are fixed, only some parameters (integer/date
format or something else) relies on the country setting, I suggest you
implement it by retrieve the params via OGNL expression.
The parameter for the Validators can be OGNL expression.
These docs may help:
http://struts.apache.org/2.x/docs/ognl.html
http://commons.apache.org/ognl/language-guide.html
If your validate rules are variable, you can implement your own
Validator, and register it into struts2.
Then, you can use it in the same way as you use the Bundled Validators.
This documents may help:
http://struts.apache.org/2.x/docs/validation.html#Validation-RegisteringValidators
To learn how to write a validator, you can read the source code of
Struts2/xWork, in package
[com.opensymphony.xwork2.validator.validators]
And you can find some samples via google.
2011/11/28 Jyothrilinga Rao jyoth...@gmail.com:
Hi all,
I am currently making use of the validator and able to work-out a example
as discussed at http://struts.apache.org/2.x/docs/validation.html.
My application has a concept of user's country which is stored in
session.
Now depending on the value of this attribute stored in session, I need to
have different validation rules for the same form and action. I would
still
like to define validations outside of my action and JSP in a XML file.
Is there something out of box provided which can fulfill my requirement ?
or is there something I can extend on to fulfill this ?
Thanks,
JK.
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
