Take a look at the ClasspathConfigurationProvider as it is the class
that processes each Action class it finds. We could have it generate a
mapping for the Action class, then one for each action method it finds.
I'm not sure I see how it would really get rid of dynamic method
calling, but it would remove the need for the flag turned to "true", at
least in the mapping stage.
Don
Ted Husted wrote:
Is there a way we could work wildcards into the mix?
A useful feature of wildcards is that when "login_*" is applied to
"login_input, then "login_input" becomes a virtual action mapping.
This means that validations, messages, resources, and type
converters can be applied to login_input, as if it were an action
mapping (which it is!).
As it stands, "dynamic invocation" is handled as an internal exception
where the "login" action is tricked into executing the input method
instead of execute, but the rest of the framework still thinks we are
invoking login.execute.
I'd like the notion of a default "dynamic invocation" separator better if
(1) It created a virtual action mapping, as the wildcard code does, and
(2) It wasn't hardwired to an arbitrary character
Hmmm, (1) actually sounds a bit like what the Codebehind plugin does
for default action mappings, except that we are adding a method to the
configuration
-T.
On 11/20/06, Don Brown <[EMAIL PROTECTED]> wrote:
I disagree; I like the "old hardwired" action!method syntax and I think
it proves itself useful in this case once again. However, I'm open to a
compromise where if the dynamic invocation flag is turned off, a
method-level annotation is required.
Don
Ted Husted wrote:
> I haven't had a chance to look at the code yet, but I am not keen on
> zero-config relying on the old hardwired, dynamic invocation code, if
> that's what is going on here.
>
> -Ted.
>
> On 11/9/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
>> On 11/9/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
>>
>> >
http://localhost:8080/struts2-showcase/person/newPerson!input.action
>> ...
>> > I thought I'd find an 'input' method in the NewPersonAction
class, but
>> > instead there is just a result named input that isn't returned by
>> > anything.
>>
>> :::sigh::: As usual, just sending an email is enough to make the
>> answer appear.
>>
>> I started with the Blank app, which has
>> struts.enable.DynamicMethodInvocation = false
>> while the Showcase app doesn't, and the input method is inherited
from
>> ActionSupport.
>>
>> --
>> Wendy
---------------------------------------------------------------------
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]
