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]