You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jyothrilinga Rao <jy...@gmail.com> on 2011/11/28 04:45:46 UTC

Customizing validation

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.

Re: Customizing validation

Posted by Dave Newton <da...@gmail.com>.
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" <li...@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 <da...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

Re: Customizing validation

Posted by Li Ying <li...@gmail.com>.
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 <da...@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: Customizing validation

Posted by Dave Newton <da...@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.
On Nov 28, 2011 8:33 PM, "Li Ying" <li...@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 <da...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

Re: Customizing validation

Posted by Li Ying <li...@gmail.com>.
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 <da...@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: Customizing validation

Posted by Dave Newton <da...@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.

On Mon, Nov 28, 2011 at 7:58 PM, Li Ying <li...@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 <jy...@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">
> >          <message>You must enter a value for email.</message>
> >      </field-validator>
> >      <field-validator type="email" short-circuit="true">
> >          <message>Not a valid e-mail.</message>
> >      </field-validator>
> >  </field>
> >  <!-- Plain Validator 1 -->
> >  <validator type="expression">
> >      <param name="expression">email.equals(email2)</param>
> >      <message>Email not the same as email2</message>
> >  </validator>
> >  *</country>*
> > *<country name="AUSTRIA">
> > *   <!-- Field Validators for email2 field -->
> >  <field name="email2">
> >     <field-validator type="email">
> >          <message>Not a valid e-mail2.</message>
> >      </field-validator>
> >  </field>
> >  <!-- Plain Validator 2 -->
> >  <validator type="expression" short-circuit="true">
> >      <param name="expression">email.startsWith('mark')</param>
> >      <message>Email 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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

Re: Customizing validation

Posted by Li Ying <li...@gmail.com>.
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 <jy...@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">
>          <message>You must enter a value for email.</message>
>      </field-validator>
>      <field-validator type="email" short-circuit="true">
>          <message>Not a valid e-mail.</message>
>      </field-validator>
>  </field>
>  <!-- Plain Validator 1 -->
>  <validator type="expression">
>      <param name="expression">email.equals(email2)</param>
>      <message>Email not the same as email2</message>
>  </validator>
>  *</country>*
> *<country name="AUSTRIA">
> *   <!-- Field Validators for email2 field -->
>  <field name="email2">
>     <field-validator type="email">
>          <message>Not a valid e-mail2.</message>
>      </field-validator>
>  </field>
>  <!-- Plain Validator 2 -->
>  <validator type="expression" short-circuit="true">
>      <param name="expression">email.startsWith('mark')</param>
>      <message>Email 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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: Customizing validation

Posted by Jyothrilinga Rao <jy...@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">
          <message>You must enter a value for email.</message>
      </field-validator>
      <field-validator type="email" short-circuit="true">
          <message>Not a valid e-mail.</message>
      </field-validator>
  </field>
 <!-- Plain Validator 1 -->
  <validator type="expression">
      <param name="expression">email.equals(email2)</param>
      <message>Email not the same as email2</message>
  </validator>
 *</country>*
*<country name="AUSTRIA">
*   <!-- Field Validators for email2 field -->
  <field name="email2">
     <field-validator type="email">
          <message>Not a valid e-mail2.</message>
      </field-validator>
  </field>
  <!-- Plain Validator 2 -->
  <validator type="expression" short-circuit="true">
      <param name="expression">email.startsWith('mark')</param>
      <message>Email 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 <li...@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 <jy...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

Re: Customizing validation

Posted by Li Ying <li...@gmail.com>.
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 <jy...@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org