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 <[EMAIL PROTECTED]> 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
> [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]
