----- Original Message ----- From: "Ted Husted" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Thursday, October 16, 2003 4:37 AM Subject: Re: Struts-chain Behavior Discussion
> Jing Zhou wrote: > > 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. > > The composable request processor is what finally got Craig to "scratch > the itch", but he's been mentioning the Chain of Responsibility pattern > for some time, in several contexts (so to speak). > > I don't think it's fair to say Commons-Chain is intended to solve any > specific Struts issue. The request processor brought the work to a head, > but Chain speaks to the need for a business layer framework. The > RequestProcessor is an example of where Struts needs to utilize what > amounts to business logic. The rules we want the request processor to > follow are not uniform and subject to a RFP, but may differ from > application to application. In other words, we want to create arbitrary > request processors -- and "arbitrary" often indicates that some flavor > of business logic is in play. =:) > > It's true that the RequestProcessor is an important proof of concept, > but, it's just the beginning. IMHO, Chain is intended to provide core > utility that many business layer implementations share, which happens to > include the request processor implementation. Another likely candidate > in Struts space would be chaining validation commands. Yes. That's why I am saying it is intended to solve *initially*. Since common-chains is in sandbox status, more new concepts could be explored/debated and when it matures we'll have a solid foundation. > > -Ted. > > Jing --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
