> -----Original Message-----From: Joe Germuska [mailto:[EMAIL PROTECTED] 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.
I'm having a few fleeting ideas around what you've suggested, although I'm still not seeing a clear path that doesn't have more complexities than benefits. I'll stew on it a bit. Feel free to elaborate on the specific application of Decorator in this use case, if you have the time and inclination.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
