The page isn't there any more, but as I remember the example, the Action would be equate to the Listener and the business logic chain would equate to the Finder.
As it stands now, the Action could simply populate a Context with whatever attributes a Finder expects. It executes the "Finder" command and chooses the next page to display. The Finder Command (or Chain) might use injection or some other technique to find a implementation of a Finder interface. But, in my experience, that's really not necessary. Used properly, the Command/Chain itself provides IoC. If you want to use a different implementation, swap in a different Command. No one outside the Finder Command need know what implementation it calls. The trick is to use finely grained Commands. Depending on how much flexibility you need, the only and only task for a Command might be to put into the Context an implementation of an interface. But, all this should be extracurricular to Struts. All Struts needs to do is collect the input, pass it along to the appropriate business command, and select the next page to display. Where the business commands come from should remain an exercise for the developer. I do think it would be cool for us to lead by example, and use CoR in MailReader and other example applications. But I don't think we need to build support for CoR into Struts for applications that use Struts. It's easy enough to plug-in already. -Ted. On Fri, 18 Feb 2005 16:09:21 -0800, Shey Rab Pawo wrote: > For what it is worth: -1 > > To follow Martin Fowler's reasoning > (http://www.martinfowler.com/articles/injection.html), a > MovieLister wants to use a MovieFinder interface but needs to > create a MovieFinderImpl implementation of the MovieFinder > interface to do so. We want the MovieLister to be coupled only to > the interface and not to the implementation for all the reasons > that decoupling is supported in OOP patterns. Most importantly, we > want to be able to exchange implementations or to improve the > implemenation without changing the MovieLister class. IoC does > this. This seems to me to be very different than CoR and not > incompatible with CoR. I would like to see Action be IoC and for > RequestProcessor to be IoC and to have a default implemenation of > RequestProcessor that is CoR. This would be close to the ideal in > my mind. There are two types of plugins that are both very useful > and they do not seem to be in competition but consistent to me. > Does this make sense to anyone? > > > On Mon, 14 Feb 2005 10:12:40 -0600, Vic <[EMAIL PROTECTED]> wrote: > >> >> Frank W. Zammetti wrote: >> >>> the more the idea of making an Action >>> a Command appeals to me. >>> >>> >> +1. >> >> In essence ... less Struts and more Chain. >> 2 chains, a user chain, and a request processing chain. >> >> (even one day go as far that the user-chain.xml replaces struts- >> config.xml. The chain xml can have infinite nubmer of elements >> now. And 10 years from now... have a declerative langage... where >> all you do is write in xml what you want to happen.) >> >> >> .V >> >> -- >> Forums, Boards, Blogs and News in RiA <http://www.boardVU.com> >> >> ------------------------------------------------------------------ >> --- 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]
