You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Gujral, Irvind" <IG...@roundarch.com> on 2001/11/02 21:23:50 UTC

Unsubscribe me

Unsubsribe me!!



-----Original Message-----
From: David Winterfeldt [mailto:dwinterfeldt@yahoo.com]
Sent: Friday, November 02, 2001 2:17 PM
To: Struts Developers List
Subject: RE: Validator design considerations



--- "Sobkowski, Andrej" <An...@emergis.com>
wrote:
> Ted,
> 
> thanks for your answer.
> 
> I understand your idea of "initial validation". And
> I also agree with
> "Generally, objects should have dominion over their
> own data". But in the
> case of the validation process, IMHO the bean is the
> data used by a
> potentially external validation process (and not
> vice-versa). What if the
> validation on the same bean is different depending
> on the app context? It
> wouldn't be "clean" (for lack of better word) to
> consider both validations
> inside the bean itself (validate())... hence the
> advantage of having
> separate validation processes on the same bean
> (related to different app
> contexts i.e. different actions). Am I missing the
> point?
Since the ActionForm is directly associated to the
form, it wouldn't necessarily be shared.  But a pure
Address JavaBean could be shared by two ActionForms by
using nested properties.

> 
> >We could definately use more standard, backend
> validators, but,
> >personally, I would say that the framework object
> that calls the
> >standard validator with the property in question
> should be the
> >ActionForm, or a business object, and not the
> Action or ActionServlet
> >directly.
> 
> In the current Struts version, the validate() on the
> FormBean is called by
> the ActionServlet.performValidate(...) method, isn't
> it? The validation is
> part of the whole process that is controlled by the
> ActionServlet - from a
> "procedural" point of view - and the same applies if
> the validate() is in
> the FormBean or in the Action (the call is simply
> made on different entities
> but in the same place). Or not?
> 
> A salomonic suggestion :) we could have different
> levels of validators:
> bean-related and action-related. The first ones will
> take care of
> first-level validations that always apply to the
> bean; the second will be
> context-specific and called only if the first
> validations passed. But by
> separating the validation process (by taking it out
> of the bean itself), it
> would be possible to dynamically associate a
> validation process (validator)
> with a bean/action.
The association of a bean with a set of validation
rules is purely based on the form element's name
attribute (the key) and the value you pass into the
Validator when you initialize it to run.  Most people
use the ValidatorForm which associates the this to the
name of the form (mapping.getAttribute()).  But you
could extend the ValidatorForm and use anything for a
key and make dynamic associations if you wanted too. 
You could even apply a basic default bean validation
and then a custom one.

> 
> Example in struts-config.xml:
> <!-- Global validators: pre-defined group of
> validators -->
> <global-validator name="myValidator" 
>   <validation ... />
>   <validation ... />
> </global-validator>
> 
> <!-- Bean-specific validations -->
> <form-bean      name="myForm"
>                 type="com.mycompany.myFormBean">
>   <validation property=... /> (see previous message
> for details)
>   <validation property=... />
> </form-bean>
>   <!-- Dynamic link to global validator -->
> <form-bean      name="myForm2"
>                 type="com.mycompany.myFormBean2">
>   <validation link="myGlobalValidator" /> (link to
> validator defined above)
> </form-bean>
> 
> <!-- Action-specific validation -->
> <action    path="/myPath"
>           
> type="com.mycompany.myActionWithValidation"
>            name="myForm">
>   <validation property=... /> (see previous message
> for details)
> </action>
> 
> Again, in my personal opinion, all of the above
> would be cleaner by
> separating the validators from the beans themselves.
> Did I manage to change
> your mind? :)
If the ActionForm was just a pure data bean I would
agree, but it isn't really.  There are already a
number of layers to the current system to add and
customize funcionality.  I do like the idea of having
a base set of validations you could define and
reference.  

David

> 
> Andrej
> 
> 
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Friday, November 02, 2001 12:40 PM
> To: Struts Developers List
> Subject: Re: Validator design considerations
> 
> 
> Andrej Sobkowski wrote:
> > - The form bean itself is a "special data holder"
> and shouldn't be aware
> of
> > how its data is validated. Do you agree?
> 
> I'm not sure that I do. I like to think of the
> ActionForm as a firewall.
> If it has passes the intial validation, then I know
> it is "safe" to use,
> and can passed along to business methods. Generally,
> objects should have
> dominion over their own data.
> 
> Under the current model, the bean is not even passed
> to the Action until
> it is validated. The Action may undertake additional
> validation, usually
> in collaboration with the business model, but I
> think it is valid for an
> ActionForm to know whether it's String values pass
> some form of "prima
> facia" validation.
> 
> There is usually additional validation at the
> business logic level, but
> this is different from the type of validation we
> need on ActionForms --
> like did they even enter anything? Could it even be
> a number?
> 
> I do believe we should be able to incorporate the
> XML configuration in
> to the Struts config, so that it is near the
> ActionForm bean it
> validates, but I'm not sure if "primary" validation
> should be delegated
> to another object, if that's what you're suggesting.
> 
> 
> We could definately use more standard, backend
> validators, but,
> personally, I would say that the framework object
> that calls the
> standard validator with the property in question
> should be the
> ActionForm, or a business object, and not the Action
> or ActionServlet
> directly.
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/
> 
> 
> Andrej Sobkowski wrote:
> > 
> > Hello All,
> > 
> > I have a set of design considerations/suggestions
> for the Validation
> > Framework in Struts. Let me know if I'm totally
> missing the point.
> > 
> > I like the whole Validator approach, in particular
> the XML configuration.
> I
> > believe that's the way to go, but I'd like to
> discuss a few points.
> > 
> > DISCUSSION: The Validator is quite "linked" to
> Servlet's stuff
> > (HttpServletRequest) and to FormBean. If I got it
> right, currently the
> > Validator needs a set of parameters to be passed
> to the ValidatorAction,
> > including the bean to validate, the Field and some
> Servlet parameters.
> > 
> > In a similar way, the validation process is linked
> to the FormBean
> > (validate() in FormBean class).
> > 
> > Shouldn't they be separate?
> > - The Action should take care of the HTTP stuff
> while the Validator should
> > only have knowledge of the bean and the
> corresponding fields to be
> > validated.
> > - The form bean itself is a "special data holder"
> and shouldn't be aware
> of
> > how its data is validated. Do you agree?
> > 
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>