Paul Benedict wrote:
I have two concerns on the 1.3.x line. What do you think?
1) Spring 2.0 has fabulous support for dependency injection for Struts. In particular,
the great Autowiring(Tiles)RequestProcessor will automatically inject dependencies into
the actions as they are created. This supports the "legacy" RequestProcessor
and I have no personal plans to depart from its use. So my question today is: does the RP
in 1.3 function just as it did in 1.2? If not, I may not want to upgrade to 1.3.x until
it does.
I would be willing to bet good money that in 1.3, you could integrate
with Spring trivially easily without having to worry about an RP... just
modify the chain to inject the dependencies after the Action is
instantiated (I don't know the Commands in the chain off the top of my
head, so I can't be any more specific than that).
AFAIK, the "RP" in 1.3 does ultimately function the same as is 1.2, it
just performs that set of functions in a wholly different way. It's a
way that should make a lot of what you and Michael are talking about
rather easy to implement without actually changing any core Struts
code... that is in a nutshell the main reason for moving to the
CoR-based RP (there's probably other reasons, but I suspect that's the
most important one).
2) I learned the tough way that it is [a] impossible to write a stateless
application in Struts and [b] use Struts' locality features at the same time.
This is because Struts only stores the locale in the session, and there is no
way (currently) to move that into a cookie, or into request scope. I found
scattered code among RequestProcessor, RequestUtils and TaglibUtils which look
only into the session for the current locale.
I can't say for sure, but again, I'd bet on the power of the chain :)
Incidentally, it's not so much the CoR pattern that's helpful here, it's
the basic idea that small units of work are loosely coupled to form a
larger processing cycle. That's where the true power comes from. You
could implement that same thing without CoR (although arguably it'd
still be CoR anyway).
Paul
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
