Re: When Oh When Do We Validate?

[Pierre Métras <ge...@sympatico.ca>]

Hi Craig,

> Pierre Métras wrote:
>
> > As my design seems to be the *bad* one, I think I will have to change my
> > code (explode my actions in struts-config.xml to create action
> > /doSomethingInit and /doSomethingValid, and attach an "input" value only
to
> > /doSomethingValid, change all my JSP forms with these URL, and in the
move
> > suppress the now unused "action" parameter...). And Craig will have to
> > rollback the CVS :,-(
>
> I'm not convinced that it would need to be rolled back -- or at least not
> completely.
>
> Independent of the actions versus sub-actions question on application
> organization, you also pointed out a real problem -- in the Struts 1.0
code as
> it was before this change, consider the following scenario:
> * You declare your action to require a form bean
> * Your form bean wants to do validation
> * You forget to define an "input" parameter
>   in the action mapping
> * Struts never calls your validate() method
> * Your action method gets called, probably
>   assuming that validation was successful,
>   and relies on incorrect assumptions.

That's what happened to me. My database was corrupted because I thought that
the ActionForms information was valid when I forgot to add the "input"
attribute to the <action>.

>
> This seems like a Bad Thing for a framework to allow when the developer
simply
> forgets to update a configuration file :-(.
>
> As the code sits right this minute, processValdiate() performs the
following
> steps, where a "true" return says "go ahead and call the action".
> (A) If there is no form bean, simply return true
> (B) If the request was cancelled, simply return true
>      (higher level logic will skip the call to the action)
> (C) Call the validate() method.  If it returns no errors,
>      simply return true
> ---------- from here on you know an error occurred ----------
> (D) If this is a multipart request, roll it back
> (E) Was an input form defined?  If not, throw
>      an error 500 (internal server error) to document
>      the mis-configuration problem.
> (F) Do a RequestDispatcher.forward() to the input form,
>      and return false.
>
> >From what it sounds like, there are particular concerns about step (C) --
> validate() is always called -- and step (E) -- multipart requests are
rolled
> back on validation errors.  I don't really have a problem with either one
of
> them, but others might.
>
> Can we come to agreement on what the recommended sequence of steps should
be?

In fact, I would move the question on another view. Should the <action> tag
be a descriptive or behavioral tag? Do we want to put in it information to
define the Struts application (which classes are used, where to redirect
errors, etc.) or must we tend to put into it relations between application
organization?
In my opinion, the first situation is encountered presently: we define in
the tag the different files/classes related to that action. Tha's no more
than grouping. The problem occurs when we decide to deduce a behavior from
it: if the "input" attribute is not present, it infers that the programmer
doesn't want to have validation...

To justify this, I can imagine numerous use cases where one need or not
validation, or even partial validation (depending on the mapping). My
present conviction is that the validation is context dependant, and that the
most flexible place to take the decision to validate or not is in the
validate method itself, when the programmer can analyse the context (within
the ActionForm, or analysing the request or mapping).
So I vote for (C) and call validate all the time.

And as I said in a previous post, if you provide one of a "mustRoolback"
property in ActionForm (to allow local decisions) or a setRollback method in
servlet (for global behavior), the programmer can decide in the "validate"
method what following he wants: rollback upload or not.
Again, I vote for (D) and let the programmer take the decision.


Maybe, another adhoc solution is to add now an attribute to desactivate vali
dation, like in the ol' time of ValidatingActionForm...
    <action     path="/login"
                    type="com.acme.LoginAction"
                    input="/login.jsp"
                    validate="false"       <== doesn't fire validation
                    ... >

As you said, we can introduce other more "workflow" tags in version 1.1 to
allows the definition of a validation process from the struts-config.xml
file...

    <form-bean      name="loginForm"
                            type="com.acme.LoginForm">
        <field name="login" mandatory="true" format="alpha*" />
        <field name="password" format="alphanum*" minSize="4" maxSize="20"
/>
    </form-bean>

And then let Struts generate the ActionForm file, and why not, the JSP page?
But that's another story...


Pierre Métras.

Re: When Oh When Do We Validate?

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Jim Newsham wrote:

> Jean-Baptiste Nizet wrote:
>
> >
> > I'm thus in favor of keeping the current behavior, where the form is not
> > validated if the input element is not defined. It's just a matter of form
> > reusability and declarative programming vs classical programming.
> > Now, I wouldn't be too much against the reverse situation, where you would have
> > to specify something in the config file if you want your form NOT to be
> > validated. The best thing to do, IMHO, is to make the presence of a
> > "validateForm" element (true or false) mandatory as soon as a formAttribute is
> > defined. That way, you have the complete declarative control on the validation,
> > and you can't make errors, since the application won't deploy if you forget to
> > specify the element. Of course, you could still set it to false instead of true,
> > but that would be your entire responsibility, and would have the same
> > consequences as inadvertently returning null in your validate method.
> >
> > What do you think?
>
> I'm in favor of being able to configure validation independently of the form also.
> This allows me to use my form object for both setup of the jsp page
> ("preprocessing") and later processing the changes made by the user.  The
> pre-processing requires no validation -- in fact some of my pages broke when
> I downloaded a recent struts which always validates, causing me to revert to my
> previous struts version.
>
> An alternative would be to subclass non-validating  FormX.java to get
> ValidatingFormX.java which just overrides validate(), for all forms FormX which use
> this style.  Personally I'd rather configure this in struts-config.
>

Configurability on a per-mapping basis seems to make the most sense.  I'm going to add
an attribute to the <action> element (and a corresponding property on ActionMapping) to
make this possible.

>
> Jim Newsham

Craig

Re: When Oh When Do We Validate?

[Jim Newsham <ne...@hotu.com>]

Jean-Baptiste Nizet wrote:

>
> I'm thus in favor of keeping the current behavior, where the form is not
> validated if the input element is not defined. It's just a matter of form
> reusability and declarative programming vs classical programming.
> Now, I wouldn't be too much against the reverse situation, where you would have
> to specify something in the config file if you want your form NOT to be
> validated. The best thing to do, IMHO, is to make the presence of a
> "validateForm" element (true or false) mandatory as soon as a formAttribute is
> defined. That way, you have the complete declarative control on the validation,
> and you can't make errors, since the application won't deploy if you forget to
> specify the element. Of course, you could still set it to false instead of true,
> but that would be your entire responsibility, and would have the same
> consequences as inadvertently returning null in your validate method.
>
> What do you think?

I'm in favor of being able to configure validation independently of the form also.
This allows me to use my form object for both setup of the jsp page
("preprocessing") and later processing the changes made by the user.  The
pre-processing requires no validation -- in fact some of my pages broke when
I downloaded a recent struts which always validates, causing me to revert to my
previous struts version.

An alternative would be to subclass non-validating  FormX.java to get
ValidatingFormX.java which just overrides validate(), for all forms FormX which use
this style.  Personally I'd rather configure this in struts-config.

Jim Newsham

Re: When Oh When Do We Validate?

[Jean-Baptiste Nizet <je...@s1.com>]

Pierre Métras wrote:

> Hi Craig,
>
> > Pierre Métras wrote:
> >
> > > As my design seems to be the *bad* one, I think I will have to change my
> > > code (explode my actions in struts-config.xml to create action
> > > /doSomethingInit and /doSomethingValid, and attach an "input" value only
> to
> > > /doSomethingValid, change all my JSP forms with these URL, and in the
> move
> > > suppress the now unused "action" parameter...). And Craig will have to
> > > rollback the CVS :,-(
> >
> > I'm not convinced that it would need to be rolled back -- or at least not
> > completely.
> >
> > Independent of the actions versus sub-actions question on application
> > organization, you also pointed out a real problem -- in the Struts 1.0
> code as
> > it was before this change, consider the following scenario:
> > * You declare your action to require a form bean
> > * Your form bean wants to do validation
> > * You forget to define an "input" parameter
> >   in the action mapping
> > * Struts never calls your validate() method
> > * Your action method gets called, probably
> >   assuming that validation was successful,
> >   and relies on incorrect assumptions.
>
> That's what happened to me. My database was corrupted because I thought that
> the ActionForms information was valid when I forgot to add the "input"
> attribute to the <action>.
>
> >
> > This seems like a Bad Thing for a framework to allow when the developer
> simply
> > forgets to update a configuration file :-(.

I'm not sure this is so bad. Struts is used here as a part of a full J2EE based
application, and J2EE applications are based, in every tier, on configuration
files or deployment descriptors. For instance, you define the transactional
behavior, the database mappings etc. of EJBs in a deployment descriptor. I thus
think that everyone now understands that these deployment descriptors or
configuration files are a critical part of the application, and that as much
care should be taken in defining these files that in the coding of the classes
(if not even more).
I'm thus in favor of keeping the current behavior, where the form is not
validated if the input element is not defined. It's just a matter of form
reusability and declarative programming vs classical programming.
Now, I wouldn't be too much against the reverse situation, where you would have
to specify something in the config file if you want your form NOT to be
validated. The best thing to do, IMHO, is to make the presence of a
"validateForm" element (true or false) mandatory as soon as a formAttribute is
defined. That way, you have the complete declarative control on the validation,
and you can't make errors, since the application won't deploy if you forget to
specify the element. Of course, you could still set it to false instead of true,
but that would be your entire responsibility, and would have the same
consequences as inadvertently returning null in your validate method.

What do you think?

JB.

>
> >
> > As the code sits right this minute, processValdiate() performs the
> following
> > steps, where a "true" return says "go ahead and call the action".
> > (A) If there is no form bean, simply return true
> > (B) If the request was cancelled, simply return true
> >      (higher level logic will skip the call to the action)
> > (C) Call the validate() method.  If it returns no errors,
> >      simply return true
> > ---------- from here on you know an error occurred ----------
> > (D) If this is a multipart request, roll it back
> > (E) Was an input form defined?  If not, throw
> >      an error 500 (internal server error) to document
> >      the mis-configuration problem.
> > (F) Do a RequestDispatcher.forward() to the input form,
> >      and return false.
> >
> > >From what it sounds like, there are particular concerns about step (C) --
> > validate() is always called -- and step (E) -- multipart requests are
> rolled
> > back on validation errors.  I don't really have a problem with either one
> of
> > them, but others might.
> >
> > Can we come to agreement on what the recommended sequence of steps should
> be?
>
> In fact, I would move the question on another view. Should the <action> tag
> be a descriptive or behavioral tag? Do we want to put in it information to
> define the Struts application (which classes are used, where to redirect
> errors, etc.) or must we tend to put into it relations between application
> organization?
> In my opinion, the first situation is encountered presently: we define in
> the tag the different files/classes related to that action. Tha's no more
> than grouping. The problem occurs when we decide to deduce a behavior from
> it: if the "input" attribute is not present, it infers that the programmer
> doesn't want to have validation...
>
> To justify this, I can imagine numerous use cases where one need or not
> validation, or even partial validation (depending on the mapping). My
> present conviction is that the validation is context dependant, and that the
> most flexible place to take the decision to validate or not is in the
> validate method itself, when the programmer can analyse the context (within
> the ActionForm, or analysing the request or mapping).
> So I vote for (C) and call validate all the time.
>
> And as I said in a previous post, if you provide one of a "mustRoolback"
> property in ActionForm (to allow local decisions) or a setRollback method in
> servlet (for global behavior), the programmer can decide in the "validate"
> method what following he wants: rollback upload or not.
> Again, I vote for (D) and let the programmer take the decision.
>
> Maybe, another adhoc solution is to add now an attribute to desactivate vali
> dation, like in the ol' time of ValidatingActionForm...
>     <action     path="/login"
>                     type="com.acme.LoginAction"
>                     input="/login.jsp"
>                     validate="false"       <== doesn't fire validation
>                     ... >
>
> As you said, we can introduce other more "workflow" tags in version 1.1 to
> allows the definition of a validation process from the struts-config.xml
> file...
>
>     <form-bean      name="loginForm"
>                             type="com.acme.LoginForm">
>         <field name="login" mandatory="true" format="alpha*" />
>         <field name="password" format="alphanum*" minSize="4" maxSize="20"
> />
>     </form-bean>
>
> And then let Struts generate the ActionForm file, and why not, the JSP page?
> But that's another story...
>
> Pierre Métras.

--
Jean-Baptiste Nizet
jean-baptiste.nizet@s1.com

R&D Engineer, S1 Belgium
Kleine Kloosterstraat, 23
B-1932 Sint-Stevens Woluwe
+32 2 200 45 42