> -----Original Message----- > From: Joe Germuska [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 30, 2005 9:46 AM > To: [EMAIL PROTECTED]; [email protected] > Subject: RE: ActionContext convenience methods > > > At 8:23 AM -0600 3/30/05, <[EMAIL PROTECTED]> wrote: > > > -----Original Message----- > >> From: Joe Germuska [mailto:[EMAIL PROTECTED] > >> Sent: Monday, March 28, 2005 10:21 PM > >> To: [email protected] > >> Subject: ActionContext convenience methods > >> > >> > >> I'd like some opinions from the community here. As I get > back to > >> building out an app based around Struts 1.3, I find myself adding > >> some familiar convenience methods to my local subclass of > >> ActionContext. > >> > >> I can totally understand where some folks would not want > >> ActionContext to get too weighed down, but it also seems > like some of > >> these would be really universally convenient. I thought > I'd raise > >> the general question and then depending on responses, > potentially add > >> some of these. One reason to be hesitant would be that > ActionContext > >> is an interface, so the more we add to it, the greater burden to > >> anyone who would choose to implement it -- even if we also > provide > >> implementations in ActionContextBase. > > > >Have you considered placing the convenience methods in a decorator? > > I hadn't. Now that I think about it, I'm not sure it quite fits. > > In my current case, where I'm already subclassing the ActionContext > to provide typesafe access to my application's key request/session > scoped types, I have a good place to stick the convenience methods -- > that's not shareable with anyone else, but it means that I don't have > to worry about what's suitable for struts-core. Also, a decorator > would be complicated to use in combination with a case like my > current one where I also want to extend the ActionContext API in > application specific ways, as once the ActionContext was wrapped in > the decorator, you would no longer have access to those extensions.
Well, the decorator could be part of struts core, and could be used internally to your ActionContext subclass. That would provide a home for common idioms in the core without widening the ActionContext interface. It would provide it in the core, making it available to all, but entirely optional. And it would make the use of your subclass unchanged. - George --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
