+1
Regards
Sreekant G
@ 98404-65630
"Andrew Hill"
<[EMAIL PROTECTED] To: "Struts Users Mailing List"
<[EMAIL PROTECTED]>
idnode.com> cc:
Subject: RE: Any potential
drawbacks with this design
09/08/2003 07:32 PM
Please respond to
"Struts Users Mailing
List"
Jing sums up the situation well.
One point to add :- if it (the functionality) is applicable to all the
actions today and you decide to go with the RP approach, that doesnt mean
that tomorrow you wont suddenly need to add an action to which it should
NOT
be applied - at which point you will then either have to factor it out of
the RP into some base action anyway - or do it conditional on checking some
flag - at which point you run the risk of introducing action logics into
the
RP...
My votes with the Action approach :-)
-----Original Message-----
From: Jing Zhou [mailto:[EMAIL PROTECTED]
Sent: Monday, 8 September 2003 21:20
To: Struts Users Mailing List
Subject: Re: Any potential drawbacks with this design
There is no *drawbacks* or *advantage* design in regard to
extending Action or RequestProcessor. It depends.
The key is how you actually interpret the word "common":
-If the *common* functionality is applicable to *all* action
mappings in a given application module, you do it by
extending RequestProcessor. For example, a custom
security checking facility in RequestProcessor.
-If the *common* functionality is required to happen
before certain logic you do it by extending RequestProcessor.
For example, a custom form token checking facility
before the form bean population.
-If the *common* functionality is applicable to a sub
set of Action classes in the application module, then you do it
by extending Action. For example, a CRUD operation
for a set of business entities. And you also give other
developers a way to interpret the CRUD operation
differently when they see fit.
I could see you have good reasons to extend Action.
Jing
Netspread Carrier
http://www.netspread.com
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Cc: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Monday, September 08, 2003 5:43 AM
Subject: RE: Any potential drawbacks with this design
>
> I did look into the subclassing the RequestProcessor class as well. I am
> not sure if it can do the following
> -- throw Exceptions.
> -- NOT call the corresponding action class (instead return to a default
> page) depending on some conditions.
>
> Is there any advantage subclassing the RequestProcessor class as opposed
to
> the implementation I wrote below.
>
> Regards
> Sreekant G
> @ 98404-65630
>
>
>
> "Viral_Thakkar"
> <[EMAIL PROTECTED] To: "Struts Users
Mailing List" <[EMAIL PROTECTED]>
> fosys.com> cc:
> Subject: RE: Any
potential
drawbacks with this design
> 09/08/2003 02:36
> PM
> Please respond to
> "Struts Users
> Mailing List"
>
>
>
>
> Better extend the RequestProcessor class.
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 08, 2003 2:24 PM
> To: [EMAIL PROTECTED]
> Subject: Any potential drawbacks with this design
>
> Hi All,
>
> Please give me your comments/suggestions on the below design.
>
> I need to perform some common functionality across all the application
> action classes, so I have written an abstract MyOwnAction class
inheriting
> from STRUTS Action class. All application action classes will be
extending
> MyOwnAction class. I have overridden the execute() method in MyOwnAction
> class in which I am doing my desired common functionality. I am also
> publishing an abstract method executeTask() which should be overridden by
> the all the application action classes The executeTask() method is
called
> by the execute() method of MOwnAction class. Basically the executeTask()
is
> now the method where the application action classes will write the
> application code as opposed to execute().
>
> Regards
> Sreekant
>
>
>
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> 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]
This mail was scanned by Interscan Virus Wall of Mailserver2 at SNR, TCS, Chennai
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
