On 11/21/06, Ted Husted wrote:
Dynamic method calling isn't evil. Essentially, the framework
framework defaults a dynamic method call to execute, when no other is
specified. Wildcards utilize dynamic method calling too.
The problem is how the original dynamic method calling is
*implemented*. The original implementation doesn't create a virtual
mapping, as do wildcards and the plugin. Exception code detects the
bang, parses it out, and calls the other method -- behind the back of
the rest of the framework. It was not implemented as a first-class
feature. It's closer to a prototype feature that we never took to the
next level.
I'll look at the ClassPathProvider to see if we can use that to
On 11/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
Ah, OK, I see where you are coming from now. Sure, if you use the
classpath provider, the problem is really solved. We could create a
mapper for every action method we discover - "action", "action!execute",
"action!input" - which also has the advantage of making the
configuration browser plugin, which I think we really should promote
more, more useful.
So, are we talking about something like
1 System (by Dispatcher.init) configures all ActionMappings from XML
configurations, zero-configuration, and custom configurations ([2],
[3], [4] in the source code).
2 System iterates over the set of namespaces and the set of
actionNames and retrieves each ActionConfig
3 For each ActionConfig, system inspects the className class for
non-void, no-argument methods
4 For each qualifying method, system looks for another actionName in
the same namespace that equals action.name + "!" + method.name
5 If that actionName is not found, System copies the ActionConfig,
changes the method property, and adds it to the package configuration
under the new actionName (action!method)
In that way, all potential action methods would have a proper
ActionConfig. As a result
* Any method can be accessed using the action!method syntax with no
extra configuration
* All potential action!methods can be browsed
* Dynamic action!methods can be overridden with configured actions, as needed
* Dynamic action!methods can have their own validators, converters,
and resources
* Exception code that scans each request for a action!method string
can be eliminated
For 2, we could make good use of the ConfigurationHelper in the
browser plugin. Any reason why shouldn't pull it back into the core,
so both can use it>
For 3, are there any existing X2 or S2 utilities that we could use, or
it would it be straight reflection?
For 5, I wonder if it would be worth having a delegating ActionConfig,
so that we could just pass in the original ActionConfig instance, and
pass through everything but the method name.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
