> -----Original Message-----
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
==////==
>
> 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.CommandAction
> SubclassingChainAction"
> >
> <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.
Yes I also thought of this idea of a map of custom properties.
>
> 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.
Some period of experimentation, trial and error, discussion is required
before any permanent decision is built into the syntax / API.
> 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.
I was thinking in truth, only providing access to the ``catalog'' and
``command'' not necessarily changing the execution model.
But if that is the case, could a Struts ``Action'' as it appears in 1.2.6
actually be a commons chain `Command' type? If it is, then,
it opens the doors for the ``chaining action'' conundrum all again.
<set-property key="catalog" value="fooCatalog" />
<set-property key="command" value="fooCommand" />
Maybe the ``set-property'' attributes can evolve over time.
If it turns out that lots of developers are writing the same
XML code over, then at some point we can migrate it to
proper attributes. We 'd have ease their deployment.
My approach would be beneficial to tool vendors, because it
is easier to parse the XML for `catalog="fooCatalog"' and
`value="fooCommand"' than to analyse the mapping properties
of an ActionConfig.
> 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.
>
Yes I think that would be possible, removing the ActionMapping
depedence. I suppose you could also refactor that code into a
composable request processor / chain implementation.
I am sure you'ill agree there is going to be more way to slice a
big cheese in half! It's is going to be, therefore, a lot more
difficult for tool vendors to say what is the best practice
for future Struts project. I am worried that there is already
XML Configuration Hell tidal wave, -- no. strike that --,
more like flooding in the coast line.
> 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]
