----- Original Message ----- From: "PILGRIM, Peter, FM" <[EMAIL PROTECTED]> To: "'Struts Developers List'" <[EMAIL PROTECTED]> Sent: Thursday, October 16, 2003 5:09 AM Subject: RE: Struts-chain Behavior Discussion
> > -----Original Message----- > > From: Jing Zhou [mailto:[EMAIL PROTECTED] > > > > ----- Original Message ----- > > From: "PILGRIM, Peter, FM" <[EMAIL PROTECTED]> > > To: "'Struts Developers List'" <[EMAIL PROTECTED]> > > Sent: Monday, October 13, 2003 5:39 AM > > Subject: RE: Struts-chain Behavior Discussion > > > > > > > *Question of Architecture* > > > > > > Does this mean that we have solved the hideous Action > > Chaining debate? > > > In theory an Struts Action could be refactored to be a type of > > > ``Command'' and therefor Actions could be chained. > > > > Whenever there is a debate and each side seems to be very reasonable > > in certain contexts, it is more likely the system itself is > > in-complete or > > fails to meet the requirements. We use Controller Delegation Model > > and/or Event Handler(s) to deal with such problems. > > > > What are you talking about here? What I am talking about or rather > aiming the ability create common Struts components. I am talking about the Action Chaining debate (if we refer to the same problem) could be solved with fine grained controls in Action if the extended Action classes could provide event handlers or delegation model, or other similar facility. > > Commons-chain is not intended to solve that debate topic originally. > > Last year, people found when they have two RequestProcessor(s), say > > A and B, if they need to design a new RequestProcessor C that has > > methods from both A and B, the best they can do is to let C extend > > one of them, say A, and then copy the methods (possibly line by line) > > from B. So a configurable RequestProcessor is somehow needed > > to reuse portions of several RequestProcessor(s). This is what > > commons-chain is intended to solve initially. > > > > Ay Ay, Captain! I don't mean to rain on the parade. I was involved > in the composable request processor discussion way way back in the > summer. As the Expresso core committer who integrated Struts 1.1 > I found also a futuristic design issues merging the > TilesRequestProcessor and our own ExpressoRequestProcessor. > How would you merge the next processor, and the next one, and > the next one after that. > > > But the problems have not been cleanly solved in regard to > > reusability. > > When a Command is deeply coupled with other Command(s) in a > > chain through one or more flags/states in Context (say cancel flag, > > invalid token flag, invalid validation flag, etc.) its > > reusability in a > > different chain is very low in theory or very difficult to > > use (you need > > to configure many flags to get it work and subject to the condition > > the new Context offers the same set of flags). > > > > I dont understand the reusability problems. To me having > read the Gang of Four original book, the design of Chain > of Responsibilty and Craig's code and what he has said > to me (to us) on list makes this a non-issue. Actual design > pattern is a linear path. The only difference I can see is > the context, which I guess you should treat it as opaque > object any way. Since you involved in the composable RequestProcessor discussion, the intention of such design is to *reuse* as much as possible the portions of different RequestProcessor(s). Instead of creating a new RequestProcessor for slightly different requirements, commons-chain could help to configure the new RequestProcessor in terms of a chain with its commands borrowed from existing commands for other RequestProcessor chains. So we could *reuse* the commands without creating new RequestProcessor class. > > If you write a Command that need various context setting > that you should declare in the javadoc or documentation. > > > I did a little exercise to reduce the command coupling degree by > > introducing a NestCommand. Like LookupCommand to execute > > a specified chain, NestCommand always return false regardless > > what nested chain returns. So a termination of nested chains does > > not force a termination of calling chains when NestCommand > > is used. The following picture illustrates the idea: > > > > You said your NestCommand always returns `false' Correct! So it never terminates calling chains by definition. > > > Main Chain: > > NestCommand > > Nested Chain: > > NestedCommand1 > > NestedCommand2 > > NestedCommand3 > > LastCommand > > > > If any nested commands return true, the control flow will > > *jump* to LastCommand. It seems to give an answer to my > > original question without the notion of branch behavior :-) > > > > And this paragraph NestCommand can return true. This conflicts > with the first. What if NestCommand return false does that > not terminate the chain, and thus stop LastCommand from > executing. > No. NestCommand always return false. All possible execution paths are as follows: * Assuming all nested commands return false: NestCommand -> NestedCommand1 -> NestedCommand2 -> NestedCommand3 -> LastCommand * Assuming only NestedCommand1 returns true: NestCommand -> NestedCommand1 -> LastCommand * Assuming only NestedCommand2 returns true: NestCommand -> NestedCommand1 -> NestedCommand2 -> -> LastCommand * Assuming only NestedCommand3 return true: The same as the first one. Note that LastCommand get executed in all possible scenarios. > > NestedCommand2 does not need to check any flag set by > > NestedCommand1 in this way and NestedCommand3 does > > not need to check any flags set by NestedCommand1 and 2. > > They could be reused in other chains without concerning about > > flags. > > > > > > -- > Peter Pilgrim, > Struts/J2EE Consultant, RBoS FM, Risk IT > Tel: +44 (0)207-375-4923 > Jing --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
