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]
