On Tue, 15 Mar 2005 17:34:13 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> I wrote:
> >Yes... I'm sorry that that discussion has stalled. Although I don't
> >even know if that's an incremental step towards a POJO action --
> >it's practically all you need, plus a little more smarts in the
> >CreateAction command. I'll go post a ping.
>
> OK, so I actually started looking at using POJOs for Actions, and
> it's a bit trickier than I'd thought, but I may want to use it on a
> current project, so if people want to talk about it, there's a chance
> I'll get it into Struts 1.3 sooner than later...
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 like the general idea of saying that the "type" property can be an
> Action, a Command, or a pojo. Perhaps there's no point in using
> Command when you can use a pojo too?
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.
--
Martin Cooper
> My thought is that CreateAction would just check the type instance
> and if it wasn't an instance of Action, it would wrap it in a new
> class, ActionWrapper, which would take an instance and a method and
> then do the invocation in its execute method.
>
> Postulating something like ActionContextFactory.getCurrentInstance(),
> the ActionWrapper would look something like this:
>
> public class ActionWrapper extends Action {
> public ActionWrapper(Object instance, String method) {
> this.instance = instance;
> this.method = method;
> }
> public ActionForward execute(m,f,r,r) {
> Object pojo = getInstance();
> // perform reflection and invocation
> return (ActionForward)
> ActionContextFactory.getCurrentInstance().getForwardConfig();
> }
> }
>
> Does that seem like a workable approach?
>
> Along the way I was also entertaining thoughts of getting
> ActionCommand in here, but then I kept thinking "why again didn't we
> change Action to have an 'execute(ActionContext)' method"? But I
> guess if there's a way to execute POJOs then I have a ready way to
> get the current ActionContext, which is the real item of interest --
> especially if we are using a custom implementation of ActionContext
> with properties that reflect our application's request/session-scoped
> properties.
>
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
