Renato,
There is another solution that is clean.
We use one action class with multiple (3) mappings to support our
validation needs. With our editor scheme, the user proceeds to a "Top"
page where they decide to Edit an existing or Add a new item. They then
proceed to a "Detail" page where they build the item. The validations for
the Top and Detail pages are different, and we use the same form for both.
We want our server side validation failures to return to the page that
caused the failure. For the Top page, that is not an issue, since there is
only one possible page that could have caused the validation issue. We had
to address the "Edit" and "Add" pages.
For this, we have three mappings:
Top - Handles initial requests for the Top page and actions from the Top
page. In this case, the "input" attribute always returns to the same page.
This mapping uses "Top" validations.
Detail - Handles requests that originate from a detail page. This mapping
uses "Detail" validations. In this case, the "input" attribute always
points to the third mapping: ValidationFailure. We additionally add a new
attribute that points to a specialized method in the action class.
ValidationFailure - Handles requests where the detail validation failed.
Uses a different parameter for the DispatchAction than the other two
methods. Validation is set to false. The available forwards are the same
as the "Edit" and "Add" forwards that are found in the "Top" mapping.
When the "failure" method is used, it takes care of any prep work that is
needed to return to the detail page. For example, there are some DB values
that we put into the request (they should be in the session, but that's
another story) when we go to the page. The failure method handles any of
the necessary prep work. The last task is that we retrieve the parameter
that was used for the original DispatchAction and return the mapping that
will take us back to the page that caused the error.
In our case, we use LookupDispatchAction classes, and this works well and
is pretty neat. Additionally, all of our action classes extend a custom
LookupDispatchAction class that implements the "failure" method as well as
a few other things that are generic for all of action classes.
Let me know if this helps.
Nick
|---------+---------------------------->
| | "Renato Romano" |
| | <[EMAIL PROTECTED]|
| | work.com> |
| | |
| | 02/18/2004 11:18 |
| | AM |
| | Please respond to|
| | "Struts Users |
| | Mailing List" |
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
|
| cc:
|
| Subject: RE: Validator and DispatchAction
|
>------------------------------------------------------------------------------------------------------------------------------|
That's just what I supposed. DispatchAction are fine, but when you need
finer control Action fits best!! Maybe next time ;-))
Thanks anyway
Renato
____________________________________
Renato Romano
Sistemi e Telematica S.p.A.
Calata Grazie - Vial Al Molo Giano
16127 - GENOVA
e-mail: [EMAIL PROTECTED]
Tel.: 010 2712603
_____________________________________
-----Original Message-----
From: Carl Walker [mailto:[EMAIL PROTECTED]
Sent: mercoledì 18 febbraio 2004 16.43
To: Struts Users Mailing List
Subject: Re: Validator and DispatchAction
I ran into the same problem and converted all my DispatchActions to
Actions. The downside is that there are more class files, but the
mappings seem cleaner, especially in handling the 'input' attribute for
<html:errors />.
Also, using Actions lets me specify different values for the 'validate'
attribute. For example, I use the same form to lookup a records as I do
to update it. In the case of the lookup, the Action pulls an identifier
from the DynaActionForm that doesn't need to be validated
(validate=false for this mapping). In the case of the update, full
validation of all fields is required, so validate=true for this one.
Renato Romano wrote:
> I'm quite new to the validator framework, and was trying to figure out
> how to use it. My situation is:
> 1) I want to perform server side validation, and so I made my form
> extend ValidatorForm;
> 2) the action that processes my form is a DispatchAction, so I have
> methods like "edit", "save" "list", all associated with the same form;
> 3) I call http://blabla/myapp/myAction.do?methodName=edit to have the
> app present me with an empty form;
> 4) When processing this action, struts allocates the form and calls
> the validate method, which of course causes validation errors to be
> produced, and the request to be forwarded to the "input" element of my
> action, which, as usual, is the same jsp which contains the form;
> 5) since the page finds some errors (the form is empty!!) they are
> shown by the <html:errors/> tag.
>
> The only think I can imagine is to have a separate action in
> struts-config, which takes no form and simply redirects control to the
> jsp page which shows the (html) form. This should avoid Struts from
> calling the validate method, and hence <html:errors/> should show
> nothing.
>
> Of course this would change a bit the logic we already placed in the
> application actions: for example action.do?methodName=edit in our
> architecture should present an empty form, while
> action.do?m=edit&id=88 should fill the form with the properties of the
> object with id 88, and then forward to the same jsp page, which then
> shows that object ready to be modified. If my above consideration is
> correct I should define two separate actions in struts-config, and let
> the links be something like newObject.do (for the presentation of an
> empty form) and unchanged for the "loading" of an object.
>
> Is all this correct ?Are there alternative approaches? Should I quit
> server side validation and only use client-side (which does not suffer
> from this problem)? Any help is very appreciated.
>
> Renato
>
> ____________________________________
> Renato Romano
> Sistemi e Telematica S.p.A.
> Calata Grazie - Vial Al Molo Giano
> 16127 - GENOVA
>
> e-mail: [EMAIL PROTECTED]
> Tel.: 010 2712603
> _____________________________________
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
