You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Luca Zago <lz...@e-tree.com> on 2002/10/07 13:48:21 UTC

Same Action Class, same form, more submits

Hi,
I noticed in devoloping with struts a design problem, probably because I 
don't know well the framework :)
I mean that the main risk with struts is devoloping a lot of action 
classes for every micro functionality.
For example I often have a form, and in this form two submits
which must call different functions on the same data submitted by the 
form. I would like to have the same action class for all the operations 
I can perform on the same submitted data.
If my submits are:

<html:sumit property="action" value="action1" />
<html:sumit property="action" value="action2" />

I can distinguish between the sumit seleceted by the user, with a 
control on the request parameter "action" inside the Action class and 
then excute different operations according to the user submit choice.
But this is a tricky, not a nice pattern, first the value is the same 
string showed on the page.. second if I use a

<html:image src="..." property="action" value="action1" />
<html:image src="..." property="action" value="action2" />

this doesn't work anymore..because the request "action" parameter is null.
Has somebody an idea to solve this problem? Or is there in struts a 
better design pattern to face this problem?

Thank in advance to all,
Luca




-- 
Luca Zago
Senior IT Developer
_____________________________________________________

E-TREE S.p.a.  Via Fonderia 43 - 31100 Treviso (Italy)
phone +39.0422.3107
fax   +39.0422.310888
http://www.e-tree.com          http://www.webanana.com
_____________________________________________________


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


RE: Same Action Class, same form, more submits

Posted by Andrew Hill <an...@gridnode.com>.
Take a look at the DispatchAction. This does the same thing you are but
saves you some typing.

The reason why you get null in the second case is that for the html:image
tag the browser doesnt submit the value when clicked but rather submits the
x and y position of the mouse when the image was clicked using the
parameters bob.x and bob.y (where bob=whatever you specified for property).
(This isnt struts fault, but rather the brilliant way way html was defiend
to work).

This makes it a damn nuisance working out which image was clicked (short of
resorting to JavaScript to set a hidden field in the images onclick or
append a parameter to the form action). Using html:submit of course works
the way one wants it to, which is why your code works.

-----Original Message-----
From: Luca Zago [mailto:lzago@e-tree.com]
Sent: Monday, October 07, 2002 19:48
To: Struts Users Mailing List
Subject: Same Action Class, same form, more submits


Hi,
I noticed in devoloping with struts a design problem, probably because I
don't know well the framework :)
I mean that the main risk with struts is devoloping a lot of action
classes for every micro functionality.
For example I often have a form, and in this form two submits
which must call different functions on the same data submitted by the
form. I would like to have the same action class for all the operations
I can perform on the same submitted data.
If my submits are:

<html:sumit property="action" value="action1" />
<html:sumit property="action" value="action2" />

I can distinguish between the sumit seleceted by the user, with a
control on the request parameter "action" inside the Action class and
then excute different operations according to the user submit choice.
But this is a tricky, not a nice pattern, first the value is the same
string showed on the page.. second if I use a

<html:image src="..." property="action" value="action1" />
<html:image src="..." property="action" value="action2" />

this doesn't work anymore..because the request "action" parameter is null.
Has somebody an idea to solve this problem? Or is there in struts a
better design pattern to face this problem?

Thank in advance to all,
Luca




--
Luca Zago
Senior IT Developer
_____________________________________________________

E-TREE S.p.a.  Via Fonderia 43 - 31100 Treviso (Italy)
phone +39.0422.3107
fax   +39.0422.310888
http://www.e-tree.com          http://www.webanana.com
_____________________________________________________


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


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