struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Renato Romano" <r.rom...@set-network.com>
Subject RE: Validator and DispatchAction
Date Wed, 18 Feb 2004 16:18:42 GMT
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: r.romano@set-network.com
Tel.:   010 2712603
_____________________________________


-----Original Message-----
From: Carl Walker [mailto:walkerce@georgetown.edu] 
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: r.romano@set-network.com
> Tel.:   010 2712603
> _____________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message