Frank W. Zammetti
Wed, 28 Jun 2006 17:50:17 -0700
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]