Here's a better example that I just ran into:
I had getEmail() and getPassword() with @RequiredStringValidator on the
base UserAction.
When I came to test ResetPasswordAction (which only requires an email),
my execute() method was never called but I got no field errors on the
rendered page.
After some head-scratching, I realized that getPassword was required
(because it was inherited by the action) by the password was not set
because it was not in the form.
I worked around it by pushing get/set password down into all of the
actions that needed it (create/update/login) but removing it from the
ones which did not.
Kevin
j alex wrote:
Thanks for your inputs.
Kevin, can you please explain a bit more abt the "provide a new annotation
to enable/disable particular validations for particular methods" -- are you
saying that for certain actions (aka methods, i presume) you don't want the
fields to be validated, but the validation needs to be fired for certain
other methods? . My understanding is that the validators are tied to fields
and not methods - right?
Since XML validation is more documented, and is what we used in S1 - i think
i may end up going ahead with it ; but wanted to try out if things can be
done better using annotations so that we can see all in 1 file rather than
looking up 2 or more files.
Specifically, i will need some custom validators that must act on a set of
fields ; and the validation message must be customized based on the context
in which the field is used - ex : "please enter primary applicant's first
name" when firstname field is used in primaryapp and "please enter
co-applicant's first name" when firstname is used in coapp instance. Does
annotation provide enough flexibility to define resourcebundle key
substitution in this way ; and is there a way we can substitute the right
message using some kind of reflection to know which context the object is
being used ?
Code examples for these will really help.
-Joseph
On 8/7/07, Kevin Lawrence <[EMAIL PROTECTED]> wrote:
I started with annotations and wild-carded actions and I very quickly
ran into the problem of not all fields apply to every action.
I briefly considered switching to xml validations but decided instead to
stick with one method per action. I hated the duplicate code in the
actions and in struts.xml less than I hated xml validations.
I really like the idea of validation annotations but there is something
not quite flexible enough in the current design to support what I wanted
to do. I tried to think of a design that would better support my needs
but the best I could come up with is:
- keep the annotations on individual fields but
- provide a new annotation to enable/disable particular validations for
particular methods
Kevin
www.junitfactory.com
You send us code. We send back tests. For free.
Musachy Barroso wrote:
On my current project I started using annotations, but very soon my
few actions were packed with them, to the point that I had more
annotations that actual code in my actions :), so I went the xml way.
musachy
On 8/7/07, Jeromy Evans <[EMAIL PROTECTED]> wrote:
Hi Joseph,
I haven't used annotation validation since S2.0.6 so these issues may
be
a little dated.
These are my experiences:
1. I tend to use wildcards in actions. In this situation, annotations
applied to properties in an action are not appropriate as not all
validations apply for each action method. The alternative is to apply
the annotations to the action methods themselves but this approach
quickly become unwieldy (eg. 10 lines of annotations for each action
method). I found multiple XML files (one for each action method/alias)
are far superior in this case.
2. the XML approach is better documented due to its longer history with
WW.
3. In 2.0.6, annotations on multiple methods did not actually work as
implied in the documentation. All annotated validators were applied
irrespective of which action method was being called. This may have
been fixed but it was a show-stopper for us.
4. Both approaches share the disadvantage that it's easy to mistype
field names. Annoyingly the annotation doesn't help as you need to
hand-type each fieldName when its applied to an action method. The
benefit of annotations is lost.
If you choose to use only a single method in each action (eg.
execute())
then the annotation validation works well as shown on the wiki.
Hope that helps you make a decision.
Jeromy Evans
j alex wrote:
Hi,
I am about to migrate a S1 app to S2 and need to decide which route to
take
regarding validations - XML or annotations? . Our app has a lot of
custom
validators involving rules dependent on multiple fields. Is there a
specific
benefit to using annotations vs XML ?
Thanks,
Joseph
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.11.8/940 - Release Date:
6/08/2007 4:53 PM
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
