#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 MRBA AMRBA 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]
