Quoting Konstantin Shaposhnikov <[EMAIL PROTECTED]>: > 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. > best regards, > Konstantin > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
