You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Ronald Haring <Ha...@furore.com> on 2002/03/05 13:14:53 UTC

design question

Hi all,

I've studied the design paper that Ted has put up at his site
(http://husted.com/about/scaffolding/strutByStrut.htm) . Very clear
explanation Ted, it only left me with one question. In your paper you state
that every form should have its own action. However for my last project (and
my first struts project) I used the same action for most of the forms.

This action would then decide based upon a navigate field in the form :
- which formBean to create and populate
- which mapping to return

based on a large if (navigation.equals("<something>")) tree.

I submitted always to the same form, so that this ControllerAction could
perform some default behavious I liked to execute (e.g. dynamic change of
language, default SQLException handling) and that all the navigation was in
the same class. 
Somehow I have the feeling that this is not the way to go.

However on the detail screens there are links to other detail screens. These
are simple links like <a href=javascipt:goSubmit('showFirstDetailsScreen')>
... <a href=javascipt:goSubmit('showSecondeDetailsScreen')> etc etc. (where
goSubmit is a javascript function that will fill the navigate field with the
given value and then submit the form). If I want a action for every form how
should I set this so that showFirstDetailsScreen will go to the right
action, without using multiple forms (since this really screws up the html
lay-out)


Gr
Ronald 


Furore B.V.
Rijswijkstraat 175-8
Postbus 9204
1006 AE Amsterdam
tel. (020) 346 71 71
fax. (020) 346 71 77

----------------------------------------------------------------------------
---------------
The information transmitted is intended only for the person
or entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material
from any computer
----------------------------------------------------------------------------
---------------


Re: design question

Posted by Ted Husted <hu...@apache.org>.
At this point, I rarely write custom Actions any more. Now I try to use
a framework action to handle all the usual action-stuff, and pass it the
name of a business bean to invoke as part of the ActionMapping. At this
point, I'm creating moderately complex application using only the stock
actions in the scaffold package. Lots and lots of business beans, but
very action classes. 

http://cvs.apache.org/viewcvs/jakarta-struts/contrib/scaffold/src/framework/main/org/apache/scaffold/http/

What I'm thinking about now is extending ActionMapping so that it has
the same type of functionality embedded in the DispatchAction. To wit,
let you specify an object to instantiate and a method to call from the
ActionMapping. There could actually be a couple of different method
signatures to call, maybe a perform, an execute, and then an invoke that
just took a single object (the ActionForm), but have them each return a
collection. There could also be an attribute to give whatever they
return a name, and pop it into a context. 

I think we can really dispense with most actions almost completely, and
configure most everything from the Struts config, as Craig envisioned in
his workflow proposal. Most of what the Actions do is very predictible,
it's just the wee-bit of business logic in the middle that makes one
different from the other.

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Ronald Haring wrote:
> 
> Hi all,
> 
> I've studied the design paper that Ted has put up at his site
> (http://husted.com/about/scaffolding/strutByStrut.htm) . Very clear
> explanation Ted, it only left me with one question. In your paper you state
> that every form should have its own action. However for my last project (and
> my first struts project) I used the same action for most of the forms.
> 
> This action would then decide based upon a navigate field in the form :
> - which formBean to create and populate
> - which mapping to return
> 
> based on a large if (navigation.equals("<something>")) tree.
> 
> I submitted always to the same form, so that this ControllerAction could
> perform some default behavious I liked to execute (e.g. dynamic change of
> language, default SQLException handling) and that all the navigation was in
> the same class.
> Somehow I have the feeling that this is not the way to go.
> 
> However on the detail screens there are links to other detail screens. These
> are simple links like <a href=javascipt:goSubmit('showFirstDetailsScreen')>
> ... <a href=javascipt:goSubmit('showSecondeDetailsScreen')> etc etc. (where
> goSubmit is a javascript function that will fill the navigate field with the
> given value and then submit the form). If I want a action for every form how
> should I set this so that showFirstDetailsScreen will go to the right
> action, without using multiple forms (since this really screws up the html
> lay-out)
> 
> Gr
> Ronald
> 
> Furore B.V.
> Rijswijkstraat 175-8
> Postbus 9204
> 1006 AE Amsterdam
> tel. (020) 346 71 71
> fax. (020) 346 71 77
> 
> ----------------------------------------------------------------------------
> ---------------
> The information transmitted is intended only for the person
> or entity to which it is addressed and may contain confidential
> and/or privileged material. Any review, retransmission,
> dissemination or other use of, or taking of any action in
> reliance upon, this information by persons or entities other
> than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete the material
> from any computer
> ----------------------------------------------------------------------------
> ---------------

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