Pilgram, Peter wrote: -----Original Message----- > From: Jing Zhou [mailto:[EMAIL PROTECTED] > > ----- Original Message ----- > From: "PILGRIM, Peter, FM"
> To: "'Struts Developers List'" > 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 agree, common Struts components are the goal. Chains and variations on them or alternatives such as decorators, proxies and even unadulterated rejaminators are the means of getting there. --- Suppose team T1 invents a generic web search engine component. Let say another team T2 wanted to use that component, say embed it is in own JSP views using say Tiles. How does the search component forward or transfer control to the external component that T2. One way could be to use an action chain. First, one writes a Struts Action in such way that it puts a known public bean or put the bean in the form bean. Whatever. This Output Bean contains contains your search result or selected object. Second, one can generate a dynamic ActionForward that names the second Action to forward. But I am thinkgin Craig has given us an alternative option, of maybe using a Command to do this. But if and only if an Action is refactored as a Command. > 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. --- I have encountered the same problem that you describe and that Craig says commons-chain is intended to solve initially. Last summer I posted code on this list for two Struts components. I called them action wrappers after the conceptual idea behind the implementation. These components use actions to decorate other actions. They add useful behavior which is unknown to the wrapped action just as a border is unknown to a bordered graphic or window. The implementation relies on a modified request processor invoking both the wrapping action and the wrapped action. I asked for a request processor refactoring but was ignored. Hopefully, the commons-chain implementation will permit the same functionality. As long as both actions can be invoked the components can still be used. But there is another piece to the component idea. Actions (chained, wrapped, or purple) usually need data to accomplish their mission. I'm not refering to application data available in the form bean; I'm refering to data which supports the component itself. An integral part of configuring a component is making the data available to it. For Struts this means the Struts configuration file and very possibly the ActionMapping (or ActionConfig). I haven't seen discussion on this related issue. --- John A. Sessler --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search
