What about:

#5:
        A DispatchAction (struts 1.1) with a single action map entry:

        /maintainUser.do?action=create          ->>  MaintainUserAction.java
        /maintainUser.do?action=read                    ->>  MaintainUserAction.java
        /maintainuser.do?action=update          ->>  MaintainUserAction.java
        /maintainuser.do?action=delete          ->>  MaintainUserAction.java
        

        Plus associated dispatched methods to process the server side of page 
        events (lookup buttons being pressed, drop down list values changing).

        The DispatchAction class acts like a page controller for all events on 
        the page (more like coding in a GUI application ala swing).

Regards,
 
Rich
_______________________
Rich Duncan


-----Original Message-----
From: Susan Bradeen [mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 25, 2003 8:28 AM
To: Struts Users Mailing List
Subject: RE: [Poll] action mappings

+1. We found that #2 worked best for our current application. 

On 09/25/2003 03:42:52 AM shirishchandra.sakhare wrote:

> My choce would be  #2.
> 
> We are doing a quite a big struts project here and i have seen both the 
> approaches being used here.And from my experience,I thik that apprioach 
2 is 
> definately betetr,maintainable and leads to better code.
> 
> With approach 1, there is a lot of conditional code in action which will 
decide 
> what to do(Whether to read, or update etc. depending upon the parameter 
> passed).But with approach #2, the actions are really very lean handlers 
whic do 
> just one operation and hence immensely easy to understand as well as 
reuse.If I 
> need to show user info afater some save action somewhere else in the 
> application, I can just use ReadUserAction.java again with a different 
mapping 
> if required.
> 
> Regards,
> Shirish
> 
> -----Original Message-----
> From: Timo Neumann [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 25, 2003 9:37 AM
> To: Struts Users Mailing List
> Subject: Re: [Poll] action mappings
> 
> 
> Mainguy, Mike wrote:
> 
> I started with #1 but then switched to #2.
> As this is my first big struts project I might be wrong but I had the
> impression that #2 would be preferrable because with #1 I would have to
> repeat the action mapping as a string in my action classes.
> I saw that most of the respondents went with #1 so I wonder why they
> prefer it?
> 
> cheers,
> 
> Timo
> 
> > What are folks currently doing for action mappings in relation to CRUD
> > operations?
> > Are you:
> >
> > #1  creating a unique Action mapping for each atomic operation
> >     (potentially mapped to the same action class)
> >     /createUser.do     ->>  UserAction.java
> >     /readUser.do       ->>  UserAction.java
> >     /updateUser.do     ->>  UserAction.java
> >     /deleteUser.do     ->>  UserAction.java
> >
> >
> > #2  creating a unique Action mapping for each atmoic operation
> >     with each action having a unique class
> >     /createUser.do     ->>  CreateUserAction.java
> >     /readUser.do       ->>  ReadUserAction.java
> >     /updateUser.do     ->>  UpdateUserAction.java
> >     /deleteUser.do     ->>  DeleteUserAction.java
> >
> > #3  creating an aggregate action class with a unique action mapping 
with
> >     multiple operations and using form/request variable to accomplish 
CUD
> >     /editUser.do       ->> UserAction.java   (?OP=Update, ?OP=Create,
> > ?OP=Delete)
> >     /displayUser.do    ->> UserAction.java
> >
> >
> > #4  creating an aggregate action class with a unique action mapping 
with
> >     multiple operations
> >     /editUser.do       ->> EditUserAction.java
> >     /displayUser.do    ->> DisplayUserAction.java
> >
> >
> > Some other way (or a combination) ...
> 
> --
> F&F Computer Anwendungen        Tel: +49 89 51727-352
> und Unternehmensberatung GmbH   Fax: +49 89 51727-111
> Westendstr. 195                 Mail: [EMAIL PROTECTED]
> D-80686 Muenchen                http://www.ff-muenchen.de
> 
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to