Heretofore, our only support for "dynamic method invocation" (DMI) has been throug the foo!bar syntax. However, the syntax was *not* supported as a true first-class API feature. It's something we slapped in using brute force, on a catch-as-catch-can basis.
Which is fine. Many great features start out as hacks. But, it may be time to put aside the hacks and accept DMI as a first-class feature, so that "foo!bar" is just one way to employ DMI. The first proposal is to use wildcards to implement DMI. We already have a proof-of-concept for that too: the mailreader-bang application in the sandbox. * http://svn.apache.org/viewvc/struts/sandbox/trunk/struts2/apps/mailreader-bang/ As the MailReader POC shows, if we want to use wildcards to mimic the bang with a "Registration" action, we simply need to replace <action name="Registration" class="mailreader2.Registration"> with <action name="Registration!*" method="{1}" class="mailreader2.Registration""> With this small change, any reference to "Registration!input" or "Regisration!default" will do exactly what they did before: Call the "input" or "default" methods on the class mapped to the Registration action. But, there's no special case code. Instead of parsing the method out of the URI and hacking in a call to the method, in effect, we've created a new "virtual" action, with all the same settings as the original archetype -- except that the wildcard action calls the "input" or "default" method instead of execute. But, it does so in the normal course, not by virtue of a special-case hack. But, wait, there's more! Using wildcards, we don't *need* to hardcode a ! in our URI (unless we want to). Actions like "inputRegistration" work equally well. Just move the asterisk. <action name="*Registration" method="{1}" class="mailreader2.Registration""> But, wait, there's more! Remember that the comment that the wildcards created a new "virtual" action? As far as the framework is concerned, the name of the action we are processing is (say) "Registration!save". Accordingly, the "ClassName-actionName-validation.xml" syntax works for "aliases" too. A validation file named * Registration-Registration!save-validation.xml will fire whenever the "Registration!save" URI is used -- just like it were a real action mapping -- which, by virtue of wildcards, it is. :) With a wildcard DMI solution, the URI looks the same, but "!method" is *not* a parameter. It is a pattern being matched by a wildcard action mapping, which creates a virtual action mapping, with the same behavior as a conventional, static action mapping. :) At the risk of sounding biblical, wildcards have not come to destroy DMI, but to fulfill it :) HTH, Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
