On Tue, 12 Aug 2003, Byrne, Steven wrote: > Date: Tue, 12 Aug 2003 21:07:42 -0400 > From: "Byrne, Steven" <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: Struts Developers List <[EMAIL PROTECTED]> > Subject: RE: ActionForwards, et al (was SuccessAction) > > > <snip/> > > I guess I have to reiterate what others have said earlier today: how do > you deal with handling or enforcing composition order? I.e. are you > implicitly assuming/requiring that the various elements in the chain are > orthogonal with respect to changes in the input/output "stream" or > changes in state that other elements in the chain might have visibility > into? Or do you assume that the composition order is part of the > interface specification, document accordingly, and hope that your > clients will read and follow the ordering specification? >
If you're using an externally configured pipeline (as we are discussing here), you definitely rely on documentation rather than a monolithic process() method to describe the constraints on ordering. That is not as "safe" (although you can do things like provide optional plug-in points in between each standard command so that people do not normally need to tweak the standard pipeline). However, it also comes with a lot of power: * You can arbitrarily rearrange commands where the order really does not matter -- there are cases like that in the standard pipeline today, and people have sometimes subclassed RequestProcessor just to change the order for their own purposes. * You can weave together multiple chains (avoiding the problems we have today with everybody wanting to subclass the one-and-only RequestProcessor). * You can have custom chains per URL (or pattern) within a module, not just custom request processors per module. * You can omit commands for things that you don't use. For example, if you're not using container managed security, the processRoles() method is just a time waster. * You can create individual Command implementations that are fine grained and reusable in different application environments. I can imagine a library of such implementations to allow composition of pipelines like what Cocoon, or Stxx, or StrutsCX do - but allow you to build your commands in Java instead of XSLT if you want :-). * You can create Command implementations that invoke scripts in arbitrary languages, so you can incorporate logic written in a variety of scripting languages together. * You can create individual Command implementations that are unit testable, since they can clearly document their expectations for input state (in the Context) and the transformations that they intend to perform on that state. * You can solve the problems people have with action chaining today by firing off your own arbitrary chains of commands, instead of just a single Action. * You can even write a one-step pipeline that invokes a hard coded RequestProcessor-like pipeline that imposes the same ordering constraints that we have today :-). > Steve Craig > > > > > > > Yep this is looking sexy. > > > > > > > > > > Yep ... lots of interesting room for playing around here. To > > say nothing of the fact that you can compose your own request > > processor pipeline to boot. > > > > Craig > > > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
