The big question with this chaining method is how do we get them to 'play nice' with each other, where the two (or more) processors are in conflict - for example one implements code that would override what the other does such as in processLocale() - or for those methods that return an object such as processActionForm(). Where the RPs are complementary its not a problem of course.
-----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Monday, 2 June 2003 17:54 To: Struts Developers List Subject: Re: composable RequestProcessor Peter A. Pilgrim wrote: > MasterRequestProcessor master = new MasterRequestProcessor(); > master.add( TilesRequestProcessor ); > master.add( FoobarRquestProcessor ); > > Is this it? I would say that this is on the right track. Essentially, each of the process methods represent an extension point or "action". Ideally, we'd like to be able to load a separate handler for each extension point. The controller then just calls each extension point in turn. There is also the question of whether you might need more extension points. Another useful approach is the one we are taking with the validator. We can define any number of validator objects and then chain them together (using the depends clause). The request processing might work the same way as the validator processing. Each extension point is a processor. The request processor just calls a series of processors in turn, in the say way we call a series of validators in turn. The default series would be the one we are using now, but whether an application uses this set, or some other, would be up to the developer. Extensions like Tiles could then be distributed as individual processors that can be loaded into a request sub-controller, rather than as a monolithic class. Of course, the default package would come with a predefined Tiles SubController, but a developer could pull out the individual processors and assemble them as needed [two from column A, one from column B =:0)]. -Ted. -- Ted Husted, Struts in Action <http://husted.com/struts/book.html> --------------------------------------------------------------------- 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]
