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