On Mon, 2006-07-24 at 15:15 -0700, Don Brown wrote: > David Evans wrote: > > I was looking in DefaultActionMapper and am wondering about the > > compatibilityMode switch functionality. In getMapping compatibilityMode > > is used to see whether to check for the ! method idiom. I assume this is > > because it will eventually be removed because wildcard mappings make it > > redundant. But in the constructor, the PrefixTrie that's being set up is > > also checking the compatibilityMode switch to see if it should add a > > node for the "method:" prefix. Should that be there? Is there someway in > > which you can use wildcards in your mapping in order to replace the > > parameter prefix? So that the button the user clicks will determine > > which method is run? > > The problem we are addressing is the ability to explicitly specify the method > to > be invoked from the URL. Instead, users should use wildcards where this > functionality is necessary. To replace the method: prefix, you would instead > use "action:foo!input", then use a wildcard in your "foo" action name to > support > the method call. In this way, the developer has to specifically allow this, > rather than the framework keeping that door (hole?) open. >
I see, sorry, the action:foo!input thing didn't occur to me. Looking now in the webwork 2.2.2 source i see it's always been that way. dave > Don > > > > > dave > > > > > >> But, if no one is interested in working on the new API now, it should > >> not be framed as an impediment to a stable Struts 2.0 release. We > >> should judge each distribution on terms of what we have done, not on > >> what we would like to do. > >> > >> -Ted. > >> > >> > >> On 7/24/06, Hubert Rabago <[EMAIL PROTECTED]> wrote: > >>> On 7/24/06, Ted Husted <[EMAIL PROTECTED]> wrote: > >>>> -1 on changing the versioning scheme. > >>>> > >>>> But, I would be open to something like > >>>> > >>>> * Struts 2.0 == "WebWork transtional release" > >>>> * Struts 2.1 == "new API release" > >>>> * Struts 3.x == "phase 2 - the best of breed release" > >>> ...with pointers on what to consider if users should upgrade or not, > >>> and a clear explanation of what to expect in the near future. This > >>> could address Tim's initial concern (which I think is valid): > >>> > >>> "Users who don't keep completely up to date with the latest goings on > >>> will see > >>> this as the latest and greatest and start migrating to it, only to > >>> have a very rude surprise when large changes occur in 2.1, or a 3.0 > >>> arrives months later." > >>> > >>> Those three lines above, listing 2.0, 2.1 and 3.x, could be > >>> communicated on the front page, on a simple table. This would be > >>> similar to how Tomcat explains why they have three versions. Very > >>> straightforward and easy to digest. > >>> > >>> Hubert > >>> > >>> > >>>> IMHO, all the users, including ourselves, are served best when we > >>>> release early and release often. > >>>> > >>>> -Ted. > >>> --------------------------------------------------------------------- > >>> 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] > > > > > > > --------------------------------------------------------------------- > 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]
