Quoting BaTien Duong <[EMAIL PROTECTED]>: > [snip] > In fact, that is what we are attempting to do. For any atomic process, i > think there are 3 repeatable components: data collection, rule analysis > based on collected data, and desion based on the analysis. I am planning > to build these re-useable components based on the chain filter. I hope > this will stimulate the interest in the chain of commands. > > I am also looking forward to the chain of commands applied to portlet, > especially: > 1) the modeling of 2 chains: 1 for portlet action and 1 for portlet > render using the same context > 2) the passing of data fron Struts ServletWebContext to > PortletWebContext to PortletRequest and PortletResponse that will be > used on top of Pluto portlet container. > 3) the passing from portlet action to the business processor chain > so a different business chain is used in the business layer. >
If we do things correctly, most commands in the chain will not need to know whether they are in a servlet or portlet environment. For example, if you take advantage of the 'requestScope" property I described earlier in this thread will hide the distincition -- it gets attributes from an HttpServletRequest if you're in a servlet based webapp, or PortletRequest if you're in a portlet based app. In the same way, the fact that portlet requires two chains instead of one should be invisible to the individual commands themselves -- that only has to be paid attention to by the outermost controlling layer. Providing abstractions (request attributes are just a Map) in the Context object being passed around is one of the key ways that the chain pattern facilitates reuse of commands. > Many promissing uses can be happened. > > BaTien > DBGROUPS Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
