Peter:
If you haven't seen it, this is effectively what the ChainAction does, or at least what it will be doing soon.
<action-mappings>
<action path="/LocaleChange"
name="LocaleChangeForm"
type="org.apache.commons.chain.mailreader.struts.CommandActionSubclassingChainAction" > <set-property key="catalog" value="fooCatalog" /> <set-property key="command" value="fooCommand" /> <forward name="success" path="/Welcome.do" /> </action> </action-mappings>
I've got the code written to support arbitrary properties (the new 'key' attribute in set-property), but just ran out of time to write a mini Struts App to demonstrate that it actually works. The current ChainAction (in struts-chain) only looks for the command in the "default" catalog, because it predates some of the refinement of catalog management in commons-chain. That limitation was one of the motivations for adding this arbitrary map of properties to ActionConfig.
I agree that your XML config proposal is nicely concise, but I think we should get some more people using Chain commands in place of actions before making more specific changes to configuration syntax. Presumably in the model you describe, Struts would treat the presence of "command" as an alternative form to "type" or "forward" -- that is one of three substantially different execution models.
It would be possible to skip the action-mapping completely and look up a chain command based on the path, since command names can be any string -- but then we'd have to re-invent all the config which is currently wrapped up in the ActionConfig.
Joe
At 10:34 AM +0000 12/15/04, Pilgrim, Peter wrote:
Hello
I have read the Commons Chain Cookbook. http://jakarta.apache.org/commons/chain/cookbook.html
Regarding the receipe, "Call a Command from Struts", it seems to me that Struts could support the Command more directly in the ActionMapping.
Instead of relying on convention, shared database key, or action form name we could expand the ActionMapping schema directly.
<action-mappings> <action path="/LocaleChange" name="LocaleChangeForm" type="org.apache.commons.chain.mailreader.struts.CommandAction" + + catalog="fooCatalog" + command="fooCommand" + > <forward name="success" path="/Welcome.do" /> </action> </action-mappings>
Obviously the extra attributes are just java.lang.String, and the actual `CommandAction' will have to retrieve them from `ActionConfig' object, and then use them to execute the action.
"catalog=fooCatalog" is the name of the catalog in application scope. You could default this attribute to just "catalog" as in the cookbook example or the default value from `ChaingListener' "command=fooCommand" picks a chain from that catalog, which is looked up.
I just pointed that out, because "parameter" may already be used in the button or javascript controlled method ``DispatchAction''s derivatives. Also some workshops have a policy document that an ``ActionForm'' must be named `FooBar*Form', and the ``Action'' must be named `FooBar*Action' etc etc
Over to you.
-- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497
============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ==============================================================================
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]