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.
