On 9/23/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > I've recently been designing applications so that per-action-path > commands are retrieved from Spring rather than from the default > commons-chain CatalogFactory. This then makes the lifecycle of the > command an external property (based on the "singleton" attribute of a > <bean> element in a Spring beans XML file.)
We've been using a C# port of Commons Chain that uses Spring to load the Catalog and run the Chains, instead of the Digester. Works great! We're also using Spring.Web to load other objects. By using Spring to load Commands, we end up with a single set of configuration files that exposes all the objects we using under one XML schema. The exception right now is iBATIS.NET. But, I don't see why we couldn't load that object graph with Spring.Net too, so that we have one configuration to rule them all. > Of course this required custom request processing commands, since > Struts 1.3 doesn't have direct dependencies upon Spring. I keep thinking that we should be able to make object-graph loading pluggable, like Shale is starting to do with Spring versus the JSF bean manager. This is something we could look at in the Struts Core 1.5 series, when we plan to "Consider refactoring for Spring." * http://struts.apache.org/milestones.html Here, where we say "Spring", I read it to say "dependency injection", since if we do this, I think we can do it through pluggable interfaces so that there is not a hydraulic dependency on Spring per se. > The best thing I think would be to write a command which instantiated > this other arbitrary class, extracting properties from the Context to > pass to the "main" method of the arbitrary class and interpreting the > return appropriately (possibly modifying the Context as well.) +1 On 9/24/05, Joe Germuska <[EMAIL PROTECTED]> wrote: >Those are concerns for commons-chain. +1 > What we should do in the Struts core is make sure that things are > properly designed for easy extensibility. +1 Personally, I also believe that we should try harder to encourage people to move as much application logic as possible out of Struts and into a separate business or application layer. The point of using Commons Chain as the basis for Struts Core is *not* to make it easier for us to put more business logic into Struts-centric Actions or Commands. (And I'm *not* implying that anyone in this thread is encouraging that practice.) The point of using Commons Chain is to make the Struts Core easier to extend and customize so that we can do less work in Actions. As a framework, an important goal should be to make it easier for us to draw a firm line between Struts and the rest of our applications. Just as Struts Core uses Commons Chain to create it's own internal application layer, we encourage other teams to use Commons Chain -- or XWork, or POJOs -- to create their own internal application layer -- clearly separate and distinct from Struts. We should not be writing applications with Struts Core, we should be writing application *into* Struts Core, so that it's easier to write them into something else as well. (Like say, a unit testing suite!) Which I think is my queue to put some volunteer time into improving MailReader :) -- HTH, Ted. http://www.husted.com/poe/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
