struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <>
Subject Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)
Date Wed, 16 Mar 2005 05:52:00 GMT
----- Original Message ----- 
From: "Martin Cooper" <>
Sent: Wednesday, March 16, 2005 4:48 AM

> I'm not sure I see the reasoning / benefit of POJOs as Actions. The
> implication is that some method that wasn't designed to be invoked as
> a command / action can do something useful without knowing about the
> request, mapping, form bean, etc. (If it has to know about those
> things, then it might as well be a Command or an Action anyway. It's
> certainly not a POJO at that point.) That seems so unlikely as to be
> not worthwhile supporting.

I find that most of  what goes into my actions is simply wiring up and most
of those actions fit one of a limited number of templates. All thats needed
is the data from the form and a method in the model. I rarely interact
directly with the Request/Session (most of thats in some "standard" code)
and the flavours of forwards associated with mappings is limited - (e.g.
sucess or failure). One scenario would be to have an IoC container create a
POJO and inject whatever resources it needed, populate it from the form data
and execute a method. The only thing remaining is having a mechanism to
determine where to forward.

> Actually, this type of overloading already leads to hard-to-track-down
> problems in other parts of Struts. For example, we overload the 'path'
> attribute of <forward>s so that it can be a path or a tile. If, for
> some reason, your Tiles definitions don't get loaded at startup time,
> the first time Struts tries to use a <forward> with a tile value, the
> user gets a weird error about illegal path syntax.
> In short, I'd discourage overloading attributes for multiple purposes,
> because it will make it hard to determine what goes wrong when there's
> a problem.

I agree this would be an issue, but could probably be resolved with better
error handling / diagnostics. Apparently Tapestry has customized digester to
report the position in a config file for an error - sounds like
errors/debugging is one of its strengths and maybe something we could
improve on.

> --
> Martin Cooper

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message