> -----Ursprüngliche Nachricht-----
> Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
> Gesendet: Samstag, 10. September 2005 18:47
> An: Struts Users Mailing List
> Betreff: Re: AW: Who decides?
>
> Leon Rosenberg wrote:
> > I think they 'de facto' are stateless singletons? I mean the
> > controller only creates one instance, and you shouldn't
> create another
> > :-)
>
> That is how it currently works, and Craig has in the past
> explained the decision. It made perfect sense 4+ years ago
> when he first wrote Struts, on the basis of performance.
> Modern JVMs make those concerns no longer true though.
>
> If an Action was created per request, you could do some
> things that you can't do now, like non-static class members.
> This would not be a huge change to the Struts codebase (at
> least, that was my conclusion when I thought about it some
> months ago and looked at the code), but would open up a lot
> of nice possibilities.
Hmm, ok, than I must have misunderstood him. Nevertheless, aren't we talking
about a virutal three-liner here, which works with existing code as well?
Interface ActionCommand{
public ActionMapping execute(...);
}
Interface ActionCommandFactory(){
public ActionCommand createCommand();
}
And then a basic action:
CommandEnabledAction extends Action{
execute(...){
ActionCommandFactory factory = lookupFactory(...);
return factory.createCommand().execute();
}
}
Now implement an extension to the config to specify a factory, and you are
done, aren't you?
Regards
Leon
>
> One could go even further and quite easily add the ability to
> specify scope for an Action, so you could put them in session
> if you wanted.
> Then, combining your ActionForms and your Actions would be
> trivially easy... and hey, that starts to look a lot more
> like JSF/Shale, doesn't it?!? ;)
>
> >>* Totally dependent on Servlet API objects, making (a) unit tests
> >>hard, and (b) implementations on portlet difficult
> >
> >
> > I think it's the nature of a http framework?
>
> Not to speak for Craig, but if I understood this point
> correctly, the idea is that right now there are a number of
> places where request/response/session are passed around
> directly and accessed directly. A layer of abstraction
> between those places and those underlying objects would make
> unit testing easier. I can't speak on the portlet point, but
> I take his word for it.
>
> In 1.3, at least as far as the request processor chain
> commands go, you get a single Context object (ActionContext I
> think?) If your Actions also recieved that object only, and
> there were methods that you called instead of directly
> accessing request/response/session, you'd have that abstraction.
>
> As per my previous post, you could do all of this with the
> current Struts code base... well, the single Context thing
> would be a little more difficult because you couldn't replace
> what an Action looks like now without breaking backwards
> compatibility, but probably it can be done *in adddition* to
> how it is now.
>
> > Regards
> > Leon
>
> Frank
>
>
> ---------------------------------------------------------------------
> 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]
