You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2005/03/29 05:20:34 UTC
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.
Still, who could argue with something like this:
public boolean hasErrors() {
ActionMessages errors = this.getErrors();
return (errors != null && errors.size() > 0);
}
On the other hand, some could probably argue with this:
public void addGlobalError(String key) {
ActionMessages msgs = new ActionMessages();
msgs.add(ActionMessages.GLOBAL_MESSAGE, new ActionMessage(key));
this.addErrors(msgs);
}
Since I have a custom subclass of ActionContext for my app, I'm
perfectly happy to implement these far away from the Struts core;
however, if people think its for the common good to add some things
along these lines, I would be happy to do that as well. If people
can articulate any general philosophies, it might save from
repeatedly seeing who thinks what is too much or just enough.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionContext convenience methods
Posted by Joe Germuska <Jo...@Germuska.com>.
>Perhaps, although I think it's more about preventing people from
>implementing interfaces on classes which really do something else.
>In any case, the common approach in many APIs is to strongly
>encourage people to implement ActionContext by extending
>ActionContextBase, and maybe that's reason enough.
um... "reason enough?" sorry, yet another ineloquent post.
All I meant to say was "maybe having ActionContextBase gives us
enough play to change the API of ActionContext as necessary, as long
as we add implementations to ActionContextBase"
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionContext convenience methods
Posted by Dakota Jack <da...@gmail.com>.
I, for one, am of one mind with Hubert on these questions. I
particularly favor the one context option.
Jack
On Tue, 29 Mar 2005 16:36:56 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> At 3:15 PM -0600 3/29/05, Hubert Rabago wrote:
> >I think the bigger question is, what happens in the future when we
> >decide we need to make changes to the ActionContext interface? I
> >don't have an answer right now, but I felt like I needed to ask the
> >question.
> >
> >I think this is one of the reasons Craig often cites when asked about
> >the use of superclasses instead of interfaces. I certainly appreciate
> >the flexibility of making ActionContext an interface, but the cost is
> >we either lock the API or cause possible compatibility problems when
> >changes need to be made.
>
> Perhaps, although I think it's more about preventing people from
> implementing interfaces on classes which really do something else.
> In any case, the common approach in many APIs is to strongly
> encourage people to implement ActionContext by extending
> ActionContextBase, and maybe that's reason enough.
>
> >Hmm... what about separating the logic from the data? We keep
> >ActionContext close to the Context concept, mostly limited to
> >accessors to data, then we have an ActionContextUtil which contains
> >common operations on ActionContext objects. Methods such as
> >addMessages(), getMessageResources(key), and *Token() can be placed
> >there. There's still the chance of compatibility problems when
> >there's an API change on ActionContext, but this could minimize it.
>
> Yeah, I thought about this, and it's just a design style I find
> distasteful. Not horribly so, but not what I'd choose first. Still,
> it's perhaps true that it better separates conveniences from the core
> responsibility of the class.
>
> >Or you could go to the other extreme where the ActionContext
> >disappears and we stick to plain Context, then let ActionContextUtil
> >contain all the Struts-specific operations such as extracting data
> >from the map and casting them to the right class:
> >
> >return context.getMapping().findForward("success");
> >vs.
> >return contextUtil.getMapping(context).findForward("success");
>
> I suppose, but personally I don't like this one much more.
>
> Thanks for weighing in, Hubert -- looking forward to hearing some
> other opinions...
>
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionContext convenience methods
Posted by Joe Germuska <Jo...@Germuska.com>.
At 3:15 PM -0600 3/29/05, Hubert Rabago wrote:
>I think the bigger question is, what happens in the future when we
>decide we need to make changes to the ActionContext interface? I
>don't have an answer right now, but I felt like I needed to ask the
>question.
>
>I think this is one of the reasons Craig often cites when asked about
>the use of superclasses instead of interfaces. I certainly appreciate
>the flexibility of making ActionContext an interface, but the cost is
>we either lock the API or cause possible compatibility problems when
>changes need to be made.
Perhaps, although I think it's more about preventing people from
implementing interfaces on classes which really do something else.
In any case, the common approach in many APIs is to strongly
encourage people to implement ActionContext by extending
ActionContextBase, and maybe that's reason enough.
>Hmm... what about separating the logic from the data? We keep
>ActionContext close to the Context concept, mostly limited to
>accessors to data, then we have an ActionContextUtil which contains
>common operations on ActionContext objects. Methods such as
>addMessages(), getMessageResources(key), and *Token() can be placed
>there. There's still the chance of compatibility problems when
>there's an API change on ActionContext, but this could minimize it.
Yeah, I thought about this, and it's just a design style I find
distasteful. Not horribly so, but not what I'd choose first. Still,
it's perhaps true that it better separates conveniences from the core
responsibility of the class.
>Or you could go to the other extreme where the ActionContext
>disappears and we stick to plain Context, then let ActionContextUtil
>contain all the Struts-specific operations such as extracting data
>from the map and casting them to the right class:
>
>return context.getMapping().findForward("success");
>vs.
>return contextUtil.getMapping(context).findForward("success");
I suppose, but personally I don't like this one much more.
Thanks for weighing in, Hubert -- looking forward to hearing some
other opinions...
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionContext convenience methods
Posted by Hubert Rabago <hr...@gmail.com>.
I think the bigger question is, what happens in the future when we
decide we need to make changes to the ActionContext interface? I
don't have an answer right now, but I felt like I needed to ask the
question.
I think this is one of the reasons Craig often cites when asked about
the use of superclasses instead of interfaces. I certainly appreciate
the flexibility of making ActionContext an interface, but the cost is
we either lock the API or cause possible compatibility problems when
changes need to be made.
Hmm... what about separating the logic from the data? We keep
ActionContext close to the Context concept, mostly limited to
accessors to data, then we have an ActionContextUtil which contains
common operations on ActionContext objects. Methods such as
addMessages(), getMessageResources(key), and *Token() can be placed
there. There's still the chance of compatibility problems when
there's an API change on ActionContext, but this could minimize it.
Or you could go to the other extreme where the ActionContext
disappears and we stick to plain Context, then let ActionContextUtil
contain all the Struts-specific operations such as extracting data
from the map and casting them to the right class:
return context.getMapping().findForward("success");
vs.
return contextUtil.getMapping(context).findForward("success");
Just thinking out loud.
Hubert
On Mon, 28 Mar 2005 21:20:34 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> 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.
>
> Still, who could argue with something like this:
> public boolean hasErrors() {
> ActionMessages errors = this.getErrors();
> return (errors != null && errors.size() > 0);
> }
>
> On the other hand, some could probably argue with this:
> public void addGlobalError(String key) {
> ActionMessages msgs = new ActionMessages();
> msgs.add(ActionMessages.GLOBAL_MESSAGE, new ActionMessage(key));
> this.addErrors(msgs);
> }
>
> Since I have a custom subclass of ActionContext for my app, I'm
> perfectly happy to implement these far away from the Struts core;
> however, if people think its for the common good to add some things
> along these lines, I would be happy to do that as well. If people
> can articulate any general philosophies, it might save from
> repeatedly seeing who thinks what is too much or just enough.
>
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org