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.
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]
