Assuming I too did not misunderstand, which certainly is possible, that
sounds about right based on the last time I looked at doing it (this has
been something that has been discussed for as long as I can remember).
Although, I don't remember it being even *that* complex :) But, it's
been a while since I looked, and the underlying point is what's
important: instantiating an Action on a per-request basis no longer
carries the performance penalty it used to (from what I have heard...
can't say I've verified this myself), has some benefits that people
would probably appreciate, and changing the current codebase to do it is
pretty close to trivial, regardless of how one decides to actually
implement it.
Frank
Leon Rosenberg wrote:
-----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]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
