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
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]
