Re: [Poll] action mappings
I use ActionMappings to represent a use-case or client story, rather than an atomic operation. The form-bean and validator collect the data the story needs, and an Action passes those to the business layer, and return the outcome. The business layer class is specified as a parameter so that I can reuse the same standard Action for most stories. So, I suppose my answer to this poll is I don't use ActionMappings for CRUD operations. I keep the CRUD crud between the business layer and the data access objects. Unless, of course, create/retrieve/update/delete were stories from the client's perspective :) I imagine you've seen this, but ... http://www.mail-archive.com/[EMAIL PROTECTED]/msg57843.html The work on the Commons Chain is coming along nicely, and we should see some standard Command Actions showing up that just pass a context up the business layer and then pass it back to the presentation layer. So, before long, I suspect people will be talking less about Actions and more about business layer Commands and Command Chains. -Ted. Mainguy, Mike wrote: I have yet another opinion poll for struts-user... 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) ... This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Junit in Action - http://www.manning.com/massol/, Struts in Action - http://husted.com/struts/book.html, JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512. Get Ready, We're Moving Out!! - http://www.clark04.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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) ... -- FF Computer AnwendungenTel: +49 89 51727-352 und Unternehmensberatung GmbH Fax: +49 89 51727-111 Westendstr. 195 Mail: [EMAIL PROTECTED] D-80686 Muenchenhttp://www.ff-muenchen.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Poll] action mappings
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) ... -- FF Computer AnwendungenTel: +49 89 51727-352 und Unternehmensberatung GmbH Fax: +49 89 51727-111 Westendstr. 195 Mail: [EMAIL PROTECTED] D-80686 Muenchenhttp://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]
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) ... -- FF Computer AnwendungenTel: +49 89 51727-352 und Unternehmensberatung GmbH Fax: +49 89 51727-111 Westendstr. 195 Mail: [EMAIL PROTECTED] D-80686 Muenchenhttp://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]
RE: [Poll] action mappings
So far the results are as follows: #1 5 #2 1 #3 2 #4 0 I added myself to both 1 and 3 as I've done a project both ways... Now I wonder, how does everyone determine which operation you are doing? As a parameter in the action mapping? A big case-style (if else) statement? -Original Message- From: Mainguy, Mike [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: [Poll] action mappings I have yet another opinion poll for struts-user... 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) ... This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Poll] action mappings
I think for #3 it would be silly not to use a DispatchAction or LookupDispatchAction, right? It seems like you would also want DispatchAction or LookupDispatchAction for #1, but I really don't understand why people are using #1 at all. Is there some reason multiple action mappings are needed for the same Action? Matt - Original Message - From: Mainguy, Mike [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:47 AM Subject: RE: [Poll] action mappings So far the results are as follows: #1 5 #2 1 #3 2 #4 0 I added myself to both 1 and 3 as I've done a project both ways... Now I wonder, how does everyone determine which operation you are doing? As a parameter in the action mapping? A big case-style (if else) statement? -Original Message- From: Mainguy, Mike [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: [Poll] action mappings I have yet another opinion poll for struts-user... 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) ... This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - 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]
RE: [Poll] action mappings
You don't have to create a different ActionClass for every Operation with the same display/FormBean... I.E. If you use the same formbean and display component, you don't want to also always create another ActionClass... Similar to dispatchaction except you use the pathmapping instead of the request parameters. I actually wrote a variant of dispatchAction that, instead of calling a specific execute method on my ActionClass, it maps the request to another Command style class that performs an operation with only the FormBean and a security context as the input, and a List or DynaBean as the output. This let me completely decouple my data access layer from any web stuff and use request parameters to determine which business operation I was performing. -Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:54 AM To: Struts Users Mailing List Subject: Re: [Poll] action mappings I think for #3 it would be silly not to use a DispatchAction or LookupDispatchAction, right? It seems like you would also want DispatchAction or LookupDispatchAction for #1, but I really don't understand why people are using #1 at all. Is there some reason multiple action mappings are needed for the same Action? Matt - Original Message - From: Mainguy, Mike [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:47 AM Subject: RE: [Poll] action mappings So far the results are as follows: #1 5 #2 1 #3 2 #4 0 I added myself to both 1 and 3 as I've done a project both ways... Now I wonder, how does everyone determine which operation you are doing? As a parameter in the action mapping? A big case-style (if else) statement? -Original Message- From: Mainguy, Mike [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: [Poll] action mappings I have yet another opinion poll for struts-user... 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) ... This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - 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] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message
Re: [Poll] action mappings
OK, I think I understand #1 now. However, I still disagree with it ;) If you are using the same form bean and display components, you can define a single action mapping and thus eliminate duplicate configuration information in the struts-config file. I am a zealot when it comes to violations of the DRY (don't repeat yourself) principle, so in my opinion #3 is superior to #1. Before I get flamed on my strong stance here, let me just mention that I do understand #3 is unworkable if you need to use different form beans for some reason. I like your variant of DispatchAction, and will likely do something similar myself soon. So your Command class has a signature something like below, right? public List execute(ActionForm form, ISecurityInfo info) One issue I have been grappling with over the last couple days is whether your're really decoupling yourself from the Web by using an ActionForm as your transfer object. The ActionForm class seems pretty tightly coupled to the servlet API to me. Sure its methods don't return or take as parameters anything directly from the javax.servlet.* API, but it does return references to things like the ActionServlet which clearly are dependent on the servlet API. Thoughts? Matt - Original Message - From: Mainguy, Mike [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:59 AM Subject: RE: [Poll] action mappings You don't have to create a different ActionClass for every Operation with the same display/FormBean... I.E. If you use the same formbean and display component, you don't want to also always create another ActionClass... Similar to dispatchaction except you use the pathmapping instead of the request parameters. I actually wrote a variant of dispatchAction that, instead of calling a specific execute method on my ActionClass, it maps the request to another Command style class that performs an operation with only the FormBean and a security context as the input, and a List or DynaBean as the output. This let me completely decouple my data access layer from any web stuff and use request parameters to determine which business operation I was performing. -Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:54 AM To: Struts Users Mailing List Subject: Re: [Poll] action mappings I think for #3 it would be silly not to use a DispatchAction or LookupDispatchAction, right? It seems like you would also want DispatchAction or LookupDispatchAction for #1, but I really don't understand why people are using #1 at all. Is there some reason multiple action mappings are needed for the same Action? Matt - Original Message - From: Mainguy, Mike [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:47 AM Subject: RE: [Poll] action mappings So far the results are as follows: #1 5 #2 1 #3 2 #4 0 I added myself to both 1 and 3 as I've done a project both ways... Now I wonder, how does everyone determine which operation you are doing? As a parameter in the action mapping? A big case-style (if else) statement? -Original Message- From: Mainguy, Mike [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: [Poll] action mappings I have yet another opinion poll for struts-user... 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) ... This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly
RE: [Poll] action mappings
Thats what prompted me to vote for 2...
Why to have unnecessary have this case statement in every action?
HAve the actions as simple handlers.Performing just simple atomic operations and
acting on whatever configuration they are provided to decide navigation
Something like
execute(){
//Getdata from form bean
//validate(if automatic validation turned off or u have special validation
requirements)
//model.getData or model.updateData
//may be form.setData
return mapping.findForward(success);
}
And the voing results are wrong..I have seen 2 votes to #2 including myself..
-Original Message-
From: Mainguy, Mike [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 3:47 PM
To: 'Struts Users Mailing List'
Subject: RE: [Poll] action mappings
So far the results are as follows:
#1 5
#2 1
#3 2
#4 0
I added myself to both 1 and 3 as I've done a project both ways... Now I
wonder, how does everyone determine which operation you are doing? As a
parameter in the action mapping? A big case-style (if else) statement?
-Original Message-
From: Mainguy, Mike [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2003 11:06 AM
To: [EMAIL PROTECTED]
Subject: [Poll] action mappings
I have yet another opinion poll for struts-user...
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) ...
This message and its contents (to include attachments) are the property of
Kmart Corporation (Kmart) and may contain confidential and proprietary
information. You are hereby notified that any disclosure, copying, or
distribution of this message, or the taking of any action based on
information contained herein is strictly prohibited. Unauthorized use of
information contained herein may subject you to civil and criminal
prosecution and penalties. If you are not the intended recipient, you should
delete this message immediately.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message and its contents (to include attachments) are the property of Kmart
Corporation (Kmart) and may contain confidential and proprietary information. You are
hereby notified that any disclosure, copying, or distribution of this message, or the
taking of any action based on information contained herein is strictly prohibited.
Unauthorized use of information contained herein may subject you to civil and criminal
prosecution and penalties. If you are not the intended recipient, you should delete
this message immediately.
-
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]
RE: [Poll] action mappings
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) ... -- FF Computer AnwendungenTel: +49 89 51727-352 und Unternehmensberatung GmbH Fax: +49 89 51727-111 Westendstr. 195 Mail: [EMAIL PROTECTED] D-80686 Muenchenhttp://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]
RE: [Poll] action mappings
That is exactly the method signature I use (well, different names, but
exactly the concept). I actually use
+++
Public string commandParameter = ProjectAction
Public List commandFoo(DynaBean bean, WebSecurityHolder security) {
..do stuff..
return ArrayList (or whatever) with a bunch of DynaBeans
}
Public DynaBean commandFoo(DynaBean bean, WebSecurityHolder security) {}
+++
Where Foo is the name of a request parameter. I have another class that acts
as a broker and maps the request parameters to these command objects.
The end result is for a request /servlet.do?ProjectAction=Foo
My BaseActionClass will automagically invoke the method Foo. In addition,
the websecurityholder has a simple method to allow you to query if the user
is in a specific role.
The cool thing is that if you use DynaForms (or DynaValidatorForms) you can
map a sql query straight into a DynaBean (or a list of) using BeanUtils and
therefore get automagic form population without a lot of muss and fuss.
I agree that #3 is probably better, but it seems that #1 is pretty popular
and I want to make sure I'm not missing some significant advantage to doing
it that way.
-Original Message-
From: Sgarlata Matt [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 10:14 AM
To: Struts Users Mailing List
Subject: Re: [Poll] action mappings
OK, I think I understand #1 now. However, I still disagree with it ;) If
you are using the same form bean and display components, you can define a
single action mapping and thus eliminate duplicate configuration information
in the struts-config file. I am a zealot when it comes to violations of the
DRY (don't repeat yourself) principle, so in my opinion #3 is superior to
#1. Before I get flamed on my strong stance here, let me just mention that
I do understand #3 is unworkable if you need to use different form beans for
some reason.
I like your variant of DispatchAction, and will likely do something similar
myself soon. So your Command class has a signature something like below,
right?
public List execute(ActionForm form, ISecurityInfo info)
One issue I have been grappling with over the last couple days is whether
your're really decoupling yourself from the Web by using an ActionForm as
your transfer object. The ActionForm class seems pretty tightly coupled to
the servlet API to me. Sure its methods don't return or take as parameters
anything directly from the javax.servlet.* API, but it does return
references to things like the ActionServlet which clearly are dependent on
the servlet API. Thoughts?
Matt
- Original Message -
From: Mainguy, Mike [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 9:59 AM
Subject: RE: [Poll] action mappings
You don't have to create a different ActionClass for every Operation
with the same display/FormBean... I.E. If you use the same formbean
and
display
component, you don't want to also always create another ActionClass...
Similar to dispatchaction except you use the pathmapping instead of
the request parameters.
I actually wrote a variant of dispatchAction that, instead of calling
a specific execute method on my ActionClass, it maps the request to
another Command style class that performs an operation with only the
FormBean and
a
security context as the input, and a List or DynaBean as the output.
This let me completely decouple my data access layer from any web
stuff and use request parameters to determine which business operation
I was performing.
-Original Message-
From: Sgarlata Matt [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 9:54 AM
To: Struts Users Mailing List
Subject: Re: [Poll] action mappings
I think for #3 it would be silly not to use a DispatchAction or
LookupDispatchAction, right? It seems like you would also want
DispatchAction or LookupDispatchAction for #1, but I really don't
understand
why people are using #1 at all. Is there some reason multiple action
mappings are needed for the same Action?
Matt
- Original Message -
From: Mainguy, Mike [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 9:47 AM
Subject: RE: [Poll] action mappings
So far the results are as follows:
#1 5
#2 1
#3 2
#4 0
I added myself to both 1 and 3 as I've done a project both ways...
Now I wonder, how does everyone determine which operation you are
doing? As a parameter in the action mapping? A big case-style (if
else) statement?
-Original Message-
From: Mainguy, Mike [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2003 11:06 AM
To: [EMAIL PROTECTED]
Subject: [Poll] action mappings
I have yet another opinion poll for struts-user...
What are folks currently doing for action mappings in relation to
CRUD operations? Are you:
#1 creating a unique Action mapping for each atomic
Re: [Poll] action mappings
How is #3 different from #5? Matt - Original Message - From: Richard J. Duncan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 10:29 AM Subject: RE: [Poll] action mappings 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) ... -- FF Computer AnwendungenTel: +49 89 51727-352 und Unternehmensberatung GmbH Fax: +49 89 51727-111 Westendstr. 195 Mail: [EMAIL PROTECTED] D-80686 Muenchenhttp://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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Poll] action mappings
#2 and #3 are, to me, flip sides of the same coin. Our team is really
divided over which is better. Currently, we're using #3 and I personally
think it's the best way, but, the argument that has been made that it is
much simpler to understand the application if there is a 1 to 1 mapping and
developers can more readily see the flow of information in a class diagram.
The other advantage that has been proposed is that you can then use your
containers security mechanism to limit access based on Role without
resorting to custom code.
My point of contention is that I don't want to have 4 classes for every
single screen (1 for Create, Read, Update, and Delete) plus 4 action
mappings... It may be ok for a simple system, but in a large system I can
see that becoming unmanageable very quickly. Not only that, but I tend to
make my apps very stateless, so, every single request needs to use the Read
operation so I end up with a bunch of duplicate code (i.e. Update and Create
also need to perhaps call read when they are done).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 10:25 AM
To: [EMAIL PROTECTED]
Subject: RE: [Poll] action mappings
Thats what prompted me to vote for 2...
Why to have unnecessary have this case statement in every action?
HAve the actions as simple handlers.Performing just simple atomic operations
and acting on whatever configuration they are provided to decide navigation
Something like
execute(){
//Getdata from form bean
//validate(if automatic validation turned off or u have special validation
requirements) //model.getData or model.updateData //may be form.setData
return mapping.findForward(success); }
And the voing results are wrong..I have seen 2 votes to #2 including
myself..
-Original Message-
From: Mainguy, Mike [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 3:47 PM
To: 'Struts Users Mailing List'
Subject: RE: [Poll] action mappings
So far the results are as follows:
#1 5
#2 1
#3 2
#4 0
I added myself to both 1 and 3 as I've done a project both ways... Now I
wonder, how does everyone determine which operation you are doing? As a
parameter in the action mapping? A big case-style (if else) statement?
-Original Message-
From: Mainguy, Mike [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2003 11:06 AM
To: [EMAIL PROTECTED]
Subject: [Poll] action mappings
I have yet another opinion poll for struts-user...
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) ...
This message and its contents (to include attachments) are the property of
Kmart Corporation (Kmart) and may contain confidential and proprietary
information. You are hereby notified that any disclosure, copying, or
distribution of this message, or the taking of any action based on
information contained herein is strictly prohibited. Unauthorized use of
information contained herein may subject you to civil and criminal
prosecution and penalties. If you are not the intended recipient, you should
delete this message immediately.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message and its contents (to include attachments) are the property of
Kmart Corporation (Kmart) and may contain confidential and proprietary
information. You are hereby notified that any disclosure, copying, or
distribution of this message, or the taking of any action based on
information contained herein is strictly prohibited. Unauthorized use of
information contained herein may subject you to civil and criminal
prosecution and penalties. If you are not the intended recipient, you should
delete this message immediately
RE: [Poll] action mappings
+1 (#3)
--- Mainguy, Mike [EMAIL PROTECTED] wrote:
#2 and #3 are, to me, flip sides of the same coin. Our team is really
divided over which is better. Currently, we're using #3 and I personally
think it's the best way, but, the argument that has been made that it is
much simpler to understand the application if there is a 1 to 1 mapping and
developers can more readily see the flow of information in a class diagram.
The other advantage that has been proposed is that you can then use your
containers security mechanism to limit access based on Role without
resorting to custom code.
My point of contention is that I don't want to have 4 classes for every
single screen (1 for Create, Read, Update, and Delete) plus 4 action
mappings... It may be ok for a simple system, but in a large system I can
see that becoming unmanageable very quickly. Not only that, but I tend to
make my apps very stateless, so, every single request needs to use the Read
operation so I end up with a bunch of duplicate code (i.e. Update and Create
also need to perhaps call read when they are done).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 10:25 AM
To: [EMAIL PROTECTED]
Subject: RE: [Poll] action mappings
Thats what prompted me to vote for 2...
Why to have unnecessary have this case statement in every action?
HAve the actions as simple handlers.Performing just simple atomic operations
and acting on whatever configuration they are provided to decide navigation
Something like
execute(){
//Getdata from form bean
//validate(if automatic validation turned off or u have special validation
requirements) //model.getData or model.updateData //may be form.setData
return mapping.findForward(success); }
And the voing results are wrong..I have seen 2 votes to #2 including
myself..
-Original Message-
From: Mainguy, Mike [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 3:47 PM
To: 'Struts Users Mailing List'
Subject: RE: [Poll] action mappings
So far the results are as follows:
#1 5
#2 1
#3 2
#4 0
I added myself to both 1 and 3 as I've done a project both ways... Now I
wonder, how does everyone determine which operation you are doing? As a
parameter in the action mapping? A big case-style (if else) statement?
-Original Message-
From: Mainguy, Mike [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2003 11:06 AM
To: [EMAIL PROTECTED]
Subject: [Poll] action mappings
I have yet another opinion poll for struts-user...
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) ...
This message and its contents (to include attachments) are the property of
Kmart Corporation (Kmart) and may contain confidential and proprietary
information. You are hereby notified that any disclosure, copying, or
distribution of this message, or the taking of any action based on
information contained herein is strictly prohibited. Unauthorized use of
information contained herein may subject you to civil and criminal
prosecution and penalties. If you are not the intended recipient, you should
delete this message immediately.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message and its contents (to include attachments) are the property of
Kmart Corporation (Kmart) and may contain confidential and proprietary
information. You are hereby notified that any disclosure, copying, or
distribution of this message, or the taking of any action based on
information contained herein is strictly prohibited. Unauthorized use of
information contained herein may subject you
RE: [Poll] action mappings
The point of being easy to understand is very important for a big application
especially I think.
And I don't understand why u need code duplication?The save action after doing update
if needs to read, the forward can point to readAction ...
That's what we have done al over our application.So to get the same screen , always
call same read action from any other save action using proper forward...
So this way you have 2 types of action in your system.openActions and save actions
.And this approach helps you to solve many other problems as well.
-Original Message-
From: Mainguy, Mike [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 4:35 PM
To: 'Struts Users Mailing List'
Subject: RE: [Poll] action mappings
#2 and #3 are, to me, flip sides of the same coin. Our team is really
divided over which is better. Currently, we're using #3 and I personally
think it's the best way, but, the argument that has been made that it is
much simpler to understand the application if there is a 1 to 1 mapping and
developers can more readily see the flow of information in a class diagram.
The other advantage that has been proposed is that you can then use your
containers security mechanism to limit access based on Role without
resorting to custom code.
My point of contention is that I don't want to have 4 classes for every
single screen (1 for Create, Read, Update, and Delete) plus 4 action
mappings... It may be ok for a simple system, but in a large system I can
see that becoming unmanageable very quickly. Not only that, but I tend to
make my apps very stateless, so, every single request needs to use the Read
operation so I end up with a bunch of duplicate code (i.e. Update and Create
also need to perhaps call read when they are done).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 10:25 AM
To: [EMAIL PROTECTED]
Subject: RE: [Poll] action mappings
Thats what prompted me to vote for 2...
Why to have unnecessary have this case statement in every action?
HAve the actions as simple handlers.Performing just simple atomic operations
and acting on whatever configuration they are provided to decide navigation
Something like
execute(){
//Getdata from form bean
//validate(if automatic validation turned off or u have special validation
requirements) //model.getData or model.updateData //may be form.setData
return mapping.findForward(success); }
And the voing results are wrong..I have seen 2 votes to #2 including
myself..
-Original Message-
From: Mainguy, Mike [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 3:47 PM
To: 'Struts Users Mailing List'
Subject: RE: [Poll] action mappings
So far the results are as follows:
#1 5
#2 1
#3 2
#4 0
I added myself to both 1 and 3 as I've done a project both ways... Now I
wonder, how does everyone determine which operation you are doing? As a
parameter in the action mapping? A big case-style (if else) statement?
-Original Message-
From: Mainguy, Mike [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2003 11:06 AM
To: [EMAIL PROTECTED]
Subject: [Poll] action mappings
I have yet another opinion poll for struts-user...
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) ...
This message and its contents (to include attachments) are the property of
Kmart Corporation (Kmart) and may contain confidential and proprietary
information. You are hereby notified that any disclosure, copying, or
distribution of this message, or the taking of any action based on
information contained herein is strictly prohibited. Unauthorized use of
information contained herein may subject you to civil and criminal
prosecution and penalties. If you are not the intended recipient, you should
delete this message
Re: [Poll] action mappings
Normally a parameter in the action mapping, but other things affect it too, such as the cancel button. And then a big case-style if else in my action superclass. On 09/25/2003 03:47 PM Mainguy, Mike wrote: So far the results are as follows: #1 5 #2 1 #3 2 #4 0 I added myself to both 1 and 3 as I've done a project both ways... Now I wonder, how does everyone determine which operation you are doing? As a parameter in the action mapping? A big case-style (if else) statement? -Original Message- From: Mainguy, Mike [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: [Poll] action mappings I have yet another opinion poll for struts-user... 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) ... This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Poll] action mappings
I just find it naturally easier to grasp what is going on with one Action and one form bean for each object in my model (and normally one factory or 'business delegate') plus a host of mappings. On 09/25/2003 03:59 PM Mainguy, Mike wrote: You don't have to create a different ActionClass for every Operation with the same display/FormBean... I.E. If you use the same formbean and display component, you don't want to also always create another ActionClass... Similar to dispatchaction except you use the pathmapping instead of the request parameters. I actually wrote a variant of dispatchAction that, instead of calling a specific execute method on my ActionClass, it maps the request to another Command style class that performs an operation with only the FormBean and a security context as the input, and a List or DynaBean as the output. This let me completely decouple my data access layer from any web stuff and use request parameters to determine which business operation I was performing. -Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:54 AM To: Struts Users Mailing List Subject: Re: [Poll] action mappings I think for #3 it would be silly not to use a DispatchAction or LookupDispatchAction, right? It seems like you would also want DispatchAction or LookupDispatchAction for #1, but I really don't understand why people are using #1 at all. Is there some reason multiple action mappings are needed for the same Action? Matt - Original Message - From: Mainguy, Mike [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:47 AM Subject: RE: [Poll] action mappings So far the results are as follows: #1 5 #2 1 #3 2 #4 0 I added myself to both 1 and 3 as I've done a project both ways... Now I wonder, how does everyone determine which operation you are doing? As a parameter in the action mapping? A big case-style (if else) statement? -Original Message- From: Mainguy, Mike [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: [Poll] action mappings I have yet another opinion poll for struts-user... 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) ... This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - 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] This message and its contents (to include attachments) are the property of Kmart Corporation
RE: [Poll] action mappings
Right, that's the way I look at it too. I guess you could call it a model or data centric perspective of the system. To me personally, any business system is centered around a logical data model. I tend to build (grow) everything from the model out to the view. It seems like the perspective you are talking about is to build the system around each atomic transaction that the system is designed to support. This is, to me, also a very valid way of looking at it, but, it seems like you would end up seeing a whole bunch of trees instead of the entire forest (if you get my drift). I like to be able to start out with a BIG picture and break it down into smaller pictures until I get the level that I'm comfortable with. It sounds like you are more comfortable with a higher level of (finer grained) detail in your implementation than I am. -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 10:44 AM To: Struts Users Mailing List Subject: Re: [Poll] action mappings I just find it naturally easier to grasp what is going on with one Action and one form bean for each object in my model (and normally one factory or 'business delegate') plus a host of mappings. On 09/25/2003 03:59 PM Mainguy, Mike wrote: You don't have to create a different ActionClass for every Operation with the same display/FormBean... I.E. If you use the same formbean and display component, you don't want to also always create another ActionClass... Similar to dispatchaction except you use the pathmapping instead of the request parameters. I actually wrote a variant of dispatchAction that, instead of calling a specific execute method on my ActionClass, it maps the request to another Command style class that performs an operation with only the FormBean and a security context as the input, and a List or DynaBean as the output. This let me completely decouple my data access layer from any web stuff and use request parameters to determine which business operation I was performing. -Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:54 AM To: Struts Users Mailing List Subject: Re: [Poll] action mappings I think for #3 it would be silly not to use a DispatchAction or LookupDispatchAction, right? It seems like you would also want DispatchAction or LookupDispatchAction for #1, but I really don't understand why people are using #1 at all. Is there some reason multiple action mappings are needed for the same Action? Matt - Original Message - From: Mainguy, Mike [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:47 AM Subject: RE: [Poll] action mappings So far the results are as follows: #1 5 #2 1 #3 2 #4 0 I added myself to both 1 and 3 as I've done a project both ways... Now I wonder, how does everyone determine which operation you are doing? As a parameter in the action mapping? A big case-style (if else) statement? -Original Message- From: Mainguy, Mike [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: [Poll] action mappings I have yet another opinion poll for struts-user... 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) ... This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately
Re: [Poll] action mappings
Very cool :)
However, I am hesitant to depend even on DynaBean. What if I want to use a
normal POJO bean? Here's what I'm thinking of doing:
IInputForm.java:
public interface IInputForm { }
IDynaInputForm.java:
public itnerface IDynaInputForm extends IInputForm {
public Object get(String name);
public void set(String name, Object object);
/* and maybe some other getters/setters like the
ones in DynaActionForm */
}
MyDynaValidatorForm.java:
public MyDynaValidatorForm extends DynaValidatorForm implements
IDynaInputForm { }
Now my execute method becomes (* added for emphasis):
public List execute(*IInputForm* form, ISecurityInfo info)
Now I'm not depending on any APIs other than my own :)
What do you think? BTW, I like that you have methods that test if a user is
in a role in your WebSecurityHolder class. I have no clue how this didn't
occur to me earlier, and will be adding this to my API in the next few
minutes.
Matt
- Original Message -
From: Mainguy, Mike [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 10:28 AM
Subject: RE: [Poll] action mappings
That is exactly the method signature I use (well, different names, but
exactly the concept). I actually use
+++
Public string commandParameter = ProjectAction
Public List commandFoo(DynaBean bean, WebSecurityHolder security) {
..do stuff..
return ArrayList (or whatever) with a bunch of DynaBeans
}
Public DynaBean commandFoo(DynaBean bean, WebSecurityHolder security) {}
+++
Where Foo is the name of a request parameter. I have another class that
acts
as a broker and maps the request parameters to these command objects.
The end result is for a request /servlet.do?ProjectAction=Foo
My BaseActionClass will automagically invoke the method Foo. In addition,
the websecurityholder has a simple method to allow you to query if the
user
is in a specific role.
The cool thing is that if you use DynaForms (or DynaValidatorForms) you
can
map a sql query straight into a DynaBean (or a list of) using BeanUtils
and
therefore get automagic form population without a lot of muss and fuss.
I agree that #3 is probably better, but it seems that #1 is pretty popular
and I want to make sure I'm not missing some significant advantage to
doing
it that way.
-Original Message-
From: Sgarlata Matt [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 10:14 AM
To: Struts Users Mailing List
Subject: Re: [Poll] action mappings
OK, I think I understand #1 now. However, I still disagree with it ;) If
you are using the same form bean and display components, you can define a
single action mapping and thus eliminate duplicate configuration
information
in the struts-config file. I am a zealot when it comes to violations of
the
DRY (don't repeat yourself) principle, so in my opinion #3 is superior to
#1. Before I get flamed on my strong stance here, let me just mention
that
I do understand #3 is unworkable if you need to use different form beans
for
some reason.
I like your variant of DispatchAction, and will likely do something
similar
myself soon. So your Command class has a signature something like below,
right?
public List execute(ActionForm form, ISecurityInfo info)
One issue I have been grappling with over the last couple days is whether
your're really decoupling yourself from the Web by using an ActionForm as
your transfer object. The ActionForm class seems pretty tightly coupled
to
the servlet API to me. Sure its methods don't return or take as
parameters
anything directly from the javax.servlet.* API, but it does return
references to things like the ActionServlet which clearly are dependent on
the servlet API. Thoughts?
Matt
- Original Message -
From: Mainguy, Mike [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 9:59 AM
Subject: RE: [Poll] action mappings
You don't have to create a different ActionClass for every Operation
with the same display/FormBean... I.E. If you use the same formbean
and
display
component, you don't want to also always create another ActionClass...
Similar to dispatchaction except you use the pathmapping instead of
the request parameters.
I actually wrote a variant of dispatchAction that, instead of calling
a specific execute method on my ActionClass, it maps the request to
another Command style class that performs an operation with only the
FormBean and
a
security context as the input, and a List or DynaBean as the output.
This let me completely decouple my data access layer from any web
stuff and use request parameters to determine which business operation
I was performing.
-Original Message-
From: Sgarlata Matt [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 9:54 AM
To: Struts Users Mailing List
Subject: Re: [Poll] action mappings
I think for #3
RE: [Poll] action mappings
Whoops!, I goofed up my response, let me clarify. From: Sgarlata Matt [mailto:[EMAIL PROTECTED] I just find it naturally easier to grasp what is going on with one Action and one form bean for each object in my model (and normally one factory or 'business delegate') plus a host of mappings. Right, that's the way I look at it too. I guess you could call it a model or data centric perspective of the system. To me personally, any business system is centered around a logical data model. I tend to build (grow) everything from the model out to the view. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] The point of being easy to understand is very important for a big application especially I think. And I don't understand why u need code duplication? The save action after doing update if needs to read, the forward can point to readAction ... That's what we have done al over our application.So to get the same screen , always call same read action from any other save action using proper forward... So this way you have 2 types of action in your system.openActions and save actions .And this approach helps you to solve many other problems as well. It seems like the perspective YOU are talking about is to build the system around each atomic transaction that the system is designed to support. This is, to me, also a very valid way of looking at it, but, it seems like you would end up seeing a whole bunch of trees instead of the entire forest (if you get my drift). I like to be able to start out with a BIG picture and break it down into smaller pictures until I get the level that I'm comfortable with. It sounds like you are more comfortable with a higher level of (finer grained) detail in your implementation than I am. This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Poll] action mappings
How is #3 different from #5? No different if you implement #3 with a DispatchAction rather than rolling your own dispatcher in your action class's execute method (a good point raised in another comment in this thread). Regards, Rich -Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 10:31 AM To: Struts Users Mailing List Subject: Re: [Poll] action mappings How is #3 different from #5? Matt - Original Message - From: Richard J. Duncan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 10:29 AM Subject: RE: [Poll] action mappings 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) ... -- FF Computer AnwendungenTel: +49 89 51727-352 und Unternehmensberatung GmbH Fax: +49 89 51727-111 Westendstr. 195 Mail: [EMAIL PROTECTED] D-80686 Muenchenhttp://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] - To unsubscribe, e-mail: [EMAIL PROTECTED
Re: [Poll] action mappings
Well to a certain extent yes I 'build the system around each atomic transaction the system is designed to support' but the atomic transactions aren't necessarily remotely atomic. Plus they are generally use-case based from the original UML design, assuming it was big enough to warrant one, and I have several points where I need transactions. I've got one page with a list of nested beans where the user can edit the parent bean and copy, move or delete the child beans all on the same submit. So I looked at the forest first, and then once I'd finished looking at it, I concentrated on the trees! On 09/25/2003 04:50 PM Mainguy, Mike wrote: Right, that's the way I look at it too. I guess you could call it a model or data centric perspective of the system. To me personally, any business system is centered around a logical data model. I tend to build (grow) everything from the model out to the view. It seems like the perspective you are talking about is to build the system around each atomic transaction that the system is designed to support. This is, to me, also a very valid way of looking at it, but, it seems like you would end up seeing a whole bunch of trees instead of the entire forest (if you get my drift). I like to be able to start out with a BIG picture and break it down into smaller pictures until I get the level that I'm comfortable with. It sounds like you are more comfortable with a higher level of (finer grained) detail in your implementation than I am. -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 10:44 AM To: Struts Users Mailing List Subject: Re: [Poll] action mappings I just find it naturally easier to grasp what is going on with one Action and one form bean for each object in my model (and normally one factory or 'business delegate') plus a host of mappings. On 09/25/2003 03:59 PM Mainguy, Mike wrote: You don't have to create a different ActionClass for every Operation with the same display/FormBean... I.E. If you use the same formbean and display component, you don't want to also always create another ActionClass... Similar to dispatchaction except you use the pathmapping instead of the request parameters. I actually wrote a variant of dispatchAction that, instead of calling a specific execute method on my ActionClass, it maps the request to another Command style class that performs an operation with only the FormBean and a security context as the input, and a List or DynaBean as the output. This let me completely decouple my data access layer from any web stuff and use request parameters to determine which business operation I was performing. -Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:54 AM To: Struts Users Mailing List Subject: Re: [Poll] action mappings I think for #3 it would be silly not to use a DispatchAction or LookupDispatchAction, right? It seems like you would also want DispatchAction or LookupDispatchAction for #1, but I really don't understand why people are using #1 at all. Is there some reason multiple action mappings are needed for the same Action? Matt - Original Message - From: Mainguy, Mike [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:47 AM Subject: RE: [Poll] action mappings So far the results are as follows: #1 5 #2 1 #3 2 #4 0 I added myself to both 1 and 3 as I've done a project both ways... Now I wonder, how does everyone determine which operation you are doing? As a parameter in the action mapping? A big case-style (if else) statement? -Original Message- From: Mainguy, Mike [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: [Poll] action mappings I have yet another opinion poll for struts-user... 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
RE: [Poll] action mappings
-Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Friday, 26 September 2003 2:14 a.m. To: Struts Users Mailing List Subject: Re: [Poll] action mappings OK, I think I understand #1 now. However, I still disagree with it ;) If you are using the same form bean and display components, you can define a single action mapping and thus eliminate duplicate configuration information in the struts-config file. In my case I am using style #1 because some actions require the form bean to be validated and some do not. I did not like the idea of conditioning the validation in the form bean validate() method. Anyone have thoughts or comments on that? Shane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Poll] action mappings
When I am using design #3 my action mappings always specify that validate=false. Those methods that do require validation explicitly call the validate method of the bean. Those methods that do not require validation don't call the method. So no conditioning is needed in the form bean for design #3 :) Matt - Original Message - From: Shane Mingins [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 4:42 PM Subject: RE: [Poll] action mappings -Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Friday, 26 September 2003 2:14 a.m. To: Struts Users Mailing List Subject: Re: [Poll] action mappings OK, I think I understand #1 now. However, I still disagree with it ;) If you are using the same form bean and display components, you can define a single action mapping and thus eliminate duplicate configuration information in the struts-config file. In my case I am using style #1 because some actions require the form bean to be validated and some do not. I did not like the idea of conditioning the validation in the form bean validate() method. Anyone have thoughts or comments on that? Shane - 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]
RE: [Poll] action mappings
-Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Friday, 26 September 2003 8:55 a.m. To: Struts Users Mailing List Subject: Re: [Poll] action mappings When I am using design #3 my action mappings always specify that validate=false. Those methods that do require validation explicitly call the validate method of the bean. Those methods that do not require validation don't call the method. So no conditioning is needed in the form bean for design #3 :) Matt Aha! That did not cross my mind as I played around with the different options. Thanks :-) Shane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Poll] action mappings
Personally I'd rather declare that validation occurs in an extra mapping that have to code it in my action. You lose the whole automation with the input as well. So I have 2 mappings for one action - one for starting ( for when validation fails), and one for validation. On 09/25/2003 11:01 PM Shane Mingins wrote: -Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Friday, 26 September 2003 8:55 a.m. To: Struts Users Mailing List Subject: Re: [Poll] action mappings When I am using design #3 my action mappings always specify that validate=false. Those methods that do require validation explicitly call the validate method of the bean. Those methods that do not require validation don't call the method. So no conditioning is needed in the form bean for design #3 :) Matt Aha! That did not cross my mind as I played around with the different options. Thanks :-) Shane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Poll] action mappings
Did you look at the attached text file? -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 770.822.3359 AIM:jmitchtx - Original Message - From: atta-ur rehman [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 12:59 PM Subject: Re: [Poll] action mappings hi james, could you please explain, for a struts newbie, what do you mean by quote I'm using DispatchAction with 2 abstract base actions between my actions and the dispatch action. The first one has helper methods for functionality not requiring authentication, and the second one (which extends the first) does require authentication. /quote Thanks in advance! ATTA - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 9:17 AM Subject: Re: [Poll] action mappings #1 with a twist. I'm using DispatchAction with 2 abstract base actions between my actions and the dispatch action. The first one has helper methods for functionality not requiring authentication, and the second one (which extends the first) does require authentication. By overriding the execute in the second one, it allows me additional base functionality (helper methods) and seamless session management in one place. I've attached a crude example of what I mean. -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 770.822.3359 AIM:jmitchtx - Original Message - From: Mainguy, Mike [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 11:05 AM Subject: [Poll] action mappings I have yet another opinion poll for struts-user... 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) ... This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - 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]
Re: [Poll] action mappings
Yes. I did. Frankly, I've failed to understand the role of both ManagedResourceBaseAction and AuthenticatedManagedResourceBaseAction actions! Are both these action extended from DispatchAction? and CreateUserAction extended from one of these managed resources action? or I'm completely lost? I'd appreicate if you could explain it for me. ATTA - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 10:06 AM Subject: Re: [Poll] action mappings Did you look at the attached text file? -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 770.822.3359 AIM:jmitchtx - Original Message - From: atta-ur rehman [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 12:59 PM Subject: Re: [Poll] action mappings hi james, could you please explain, for a struts newbie, what do you mean by quote I'm using DispatchAction with 2 abstract base actions between my actions and the dispatch action. The first one has helper methods for functionality not requiring authentication, and the second one (which extends the first) does require authentication. /quote Thanks in advance! ATTA - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 9:17 AM Subject: Re: [Poll] action mappings #1 with a twist. I'm using DispatchAction with 2 abstract base actions between my actions and the dispatch action. The first one has helper methods for functionality not requiring authentication, and the second one (which extends the first) does require authentication. By overriding the execute in the second one, it allows me additional base functionality (helper methods) and seamless session management in one place. I've attached a crude example of what I mean. -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 770.822.3359 AIM:jmitchtx - Original Message - From: Mainguy, Mike [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 11:05 AM Subject: [Poll] action mappings I have yet another opinion poll for struts-user... 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) ... This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - 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
Re: [Poll] action mappings
#1 with a twist. I'm using DispatchAction with 2 abstract base actions between my actions and the dispatch action. The first one has helper methods for functionality not requiring authentication, and the second one (which extends the first) does require authentication. By overriding the execute in the second one, it allows me additional base functionality (helper methods) and seamless session management in one place. I've attached a crude example of what I mean. -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 770.822.3359 AIM:jmitchtx - Original Message - From: Mainguy, Mike [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 11:05 AM Subject: [Poll] action mappings I have yet another opinion poll for struts-user... 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) ... This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] MRBA == ManagedResourceBaseAction AMRBA == AuthenticatedManagedResourceBaseAction diclaimer This diagram may seem crude, but I hope you get the idea. The formatting will most likely be screwed up. All actions (except login) must extend AMRBA. /disclaimer So, I have: /createUser.do DispatchAction MRBAAMRBA ManageUserAction | -execute()| |--, | | | isLoggedIn? | | |-' | |-- super.execute() --| | |/createUser--| | | | |--getService()---| | | | | | | | | |--createUser()- Business | | Service | | | *Note* - I do not pass return boolean or some other crappy way of dealing with invalid state. My application takes advantage of declarative exception handline - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Poll] action mappings
#1 On 09/23/2003 05:05 PM Mainguy, Mike wrote: I have yet another opinion poll for struts-user... 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) ... This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Poll] action mappings
#3 - almost all of my actions descend from DispatchAction - Original Message - From: Mainguy, Mike [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 11:05 AM Subject: [Poll] action mappings I have yet another opinion poll for struts-user... 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) ... This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - 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]
Re: [Poll] action mappings
hi james, could you please explain, for a struts newbie, what do you mean by quote I'm using DispatchAction with 2 abstract base actions between my actions and the dispatch action. The first one has helper methods for functionality not requiring authentication, and the second one (which extends the first) does require authentication. /quote Thanks in advance! ATTA - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 9:17 AM Subject: Re: [Poll] action mappings #1 with a twist. I'm using DispatchAction with 2 abstract base actions between my actions and the dispatch action. The first one has helper methods for functionality not requiring authentication, and the second one (which extends the first) does require authentication. By overriding the execute in the second one, it allows me additional base functionality (helper methods) and seamless session management in one place. I've attached a crude example of what I mean. -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 770.822.3359 AIM:jmitchtx - Original Message - From: Mainguy, Mike [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 11:05 AM Subject: [Poll] action mappings I have yet another opinion poll for struts-user... 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) ... This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - 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]
