struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <George.Dinwid...@wellsfargo.com>
Subject RE: ActionContext convenience methods
Date Wed, 30 Mar 2005 16:16:18 GMT
> -----Original Message-----
> From: Joe Germuska [mailto:Joe@germuska.com] 
> Sent: Wednesday, March 30, 2005 9:46 AM
> To: George.Dinwiddie@wellsfargo.com; dev@struts.apache.org
> Subject: RE: ActionContext convenience methods
> 
> 
> At 8:23 AM -0600 3/30/05, <George.Dinwiddie@wellsfargo.com> wrote:
> >  > -----Original Message-----
> >>  From: Joe Germuska [mailto:Joe@Germuska.com]
> >>  Sent: Monday, March 28, 2005 10:21 PM
> >>  To: dev@struts.apache.org
> >>  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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message