Yes I also thought of this idea of a map of custom properties.
Yeah, as I had mentioned in earlier discussion, it's been a pet feature request from someone on my team, and it makes possible the ChainAction when you need two config params; the alternative would be an ActionMapping which implements a two-property interface so that people could use ChainAction with their own custom subclasses of ActionConfig... and soon it's tangled mess.
> Presumably in the model you describe, Struts would treat the presenceof "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.
Yes, I think that's a good general model...
> Presumably in the model you describe, Struts would treat the presenceof "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.
Actually, this solves the 'chaining action' conundrum, because your command can actually point to a chain, where you compose a series of logical steps which execute, but which do not each require an additional pass through the rest of the RequestProcessor chain.
The "alternate execution model" is really as simple as adding two bean properties to ActionConfig and one more command in the base request processing chain. As it is now, the chain commands which deal with an action mapping which has a defined "forward" or "type" are happy to sit back and do nothing when those aren't defined. So one more command which tests the value of "command" and if its defined, looks up the command and executes it. As with the others, it would simply do nothing if it saw an ActionMapping with an undefined value for command.
Because it turns out that the ActionMapping is involved in several other steps in the process (form population and validation, most importantly), it would probably always make sense to keep the <action> config element, not least because so many people are familiar with it, and as you note, vendors are making tools that are familiar with it too...
--
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]
