struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Lee" <crazy...@crazybob.org>
Subject Re: DefaultActionMapper compatablity switch [was: Re: [s2] Roadmap (was Tag it and Roll it?)]
Date Mon, 24 Jul 2006 23:05:30 GMT
I think "method:foo" might still make sense. It's orthogonal to path
mappings. Maybe.

Bob

On 7/24/06, David Evans <dsevans@berndtgroup.net> wrote:
>
> 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 <hrabago@gmail.com> wrote:
> > >>> On 7/24/06, Ted Husted <husted@apache.org> 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: dev-unsubscribe@struts.apache.org
> > >>> For additional commands, e-mail: dev-help@struts.apache.org
> > >>>
> > >>>
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message