On Thu, 16 Dec 2004 21:47:53 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
Who is working on bringing Struts chain into Struts core? If no one, I wouldn't mind doing the integration.
I've been wondering the same thing. I have not done anything myself yet, so I'd be happy for you to take this on. ;-)
I'm thinking about using the ComposableRequestProcessor to keep as much backwards compatibility as possible. The changes I'm proposing by layer:
web.xml - A "chainConfig" parameter to override default catalog. If none specified, a default chain config will be loaded from the Struts jar. - A "chainCommand" parameter to specify the command to execute if none specified in modules (optional)
I'm probably misunderstanding something, but ComposableRequestProcessor uses two context initialisation params for these already. Those names and default values seem fine to me.
The idea of these in web.xml is the ability to specify a custom chainConfig that would be used as the default for all modules; same with the command name. My goal would be to make it possible to use an existing Struts 1.1/1.2 app without any changes. To meet this goal, all these configuration options are optional and defaults will be used if necessary.
struts-config.xml - The default request processor class would now be ComposableRequestProcessor, but the legacy ones would still be available (deprecated)
+1. One thing that I'm a little confused about, though, is that the new request processor is (currently) in a package that includes 'legacy'. Anyone know why that is?
- The controller would have additional optional attributes: - "chainConfig" - path of chain config to override default chain catalog. Cannot be used if "catalog" is specified.
Why would we need this, in addition to the catalog (below)?
- "catalog" - name of servlet context attribute to locate catalog for this module. Cannot be used of "chainConfig" is used.
Shouldn't this just be the catalog name, now that Chain has named catalogs?
You could be right, I haven't looked into named catalogs so perhaps that would be the catalog name. The "chainConfig" optional would be to let the user specify a custom chain-config.xml file for that module (overriding the default chain catalog).
- "command" - name of command to execute. Overrides default chain command name.
Do the above controller config attributes override the web.xml ones, or, if not, how do they inter-relate?
As mentioned above, these module-level configurations are all optional, and if specified, would override defaults possibly specified in web.xml.
Don
- Remove the need for the chain plugin
Yup.
If any of the above are stupid questions, my excuse is that I'm really tired, and probably shouldn't be replying tonight at all... ;-)
Of course, if someone is already doing the integration, ignore this. Otherwise, comments appreciated. I'll target the integration Sunday or Monday if I don't hear different.
Sounds great!
-- Martin Cooper
Don
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
