Quoting Konstantin Shaposhnikov <[EMAIL PROTECTED]>: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.
Thank you for quick response and your ideas about the
implementation.
But can I ask you why I can't use the second
approach with struts 1.1. I explore struts-chain code once
again and found that I only need to change 1 Command in
servlet-standard chain.
You can certainly customize the chain if you want to use it with Struts 1.1, but that means you are playing with unreleased code and having to live with whatever restrictions exist (for instance, file upload is not currently supported in the existing chain definitions).
I am imagining a day where we'd build the standard RequestProcessor for Struts 1.2 on top of the chain implementation.
And what means "provided for backwards compatibility with Struts 1.1" ? Will the next release replace Actions with something else?
One of the key things people would look for from Struts 1.2 is a relatively easy migration of existing Struts-based apps. Therefore, it would seem best for us to be able to call an app's existing Action classes (as the current struts-chain implementation does).
In a future world solely based on chain, you wouldn't need the idea of an Action class at all. Instead, you'd map the <action> element in struts-config.xml to the name of a chain, which could either be a single Command or a series of Commands -- Struts would not care. In this environment, there would still be a standard set of commands in the standard chain, to do all the standard stuff (like populating a form bean, performing validation, and so on). But the thinking is that the app's business logic would be built out of chains as well, which can (of course) be arbitrarily complex in their internal structure.
Among other things, this would allow people to not have to attempt to use
"action chaining", which today causes surprising results. Instead, you could
build little two-Command chains -- the first would process the form submit, and
the second would do the appropriate setup for the next page to be displayed. Because these two behaviors would be separated, you could reuse either or both
of them (for example, cases you need to forward to a particular page from more
than one place, and perform the same setup behavior each time, could share the
second command.
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.
Many promissing uses can be happened.
BaTien DBGROUPS
best regards, Konstantin
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
.
