What about this, if we an action of "invoice_submit_ajax"
 -  invoice_{*}_{*}   where {1} will gives "submit" and {2} will gives "ajax"
 - invoice_{**} where {1} will gives "submit_ajax"
 - invoice_{method}_{way} where {method} will gives "submit" and {way} will 
gives "ajax"
 - invoice_{methodAndWay} where {methodAndWay} will gives "submit_ajax"
 
 thoughts? 
 

----- Original Message ----
From: Bob Lee <[EMAIL PROTECTED]>
To: Struts Developers List <dev@struts.apache.org>
Sent: Wednesday, 26 July, 2006 1:51:06 PM
Subject: Re: Returning Result directly (was Re: DefaultActionMapper compatablity

I actually didn't understand the * scheme until someone explained it to me.
On the other hand, I think I'd grok a scheme which used explicit names
pretty quickly.

Ant may use "*/**" for paths, but you don't reference indexed parts of the
match, do you?

Bob

On 7/25/06, Don Brown <[EMAIL PROTECTED]> wrote:
>
> Good ideas.  The question is really what would be most intuitive and
> cover the most common use cases.  The */** syntax seems pretty common,
> and, IMO, very intuitive used in tools like Ant.  If we abstract the
> wildcard handling, we could allow users to switch in a new impl easily
> for more advanced cases.  That said, I'm open to changing the default
> wildcard pattern style if we find one that is more powerful, yet still
> easy and intuitive.
>
> Don
>
> Bob Lee wrote:
> > {foo*} could match slashes. Or {/foo}. Or {{foo}}.
> >
> > We could also use regular expressions--they support this sort of group
> > matching and results.
> >
> > Bob
> >
> > On 7/25/06, Don Brown <[EMAIL PROTECTED]> wrote:
> >>
> >> Struts 2 (XWork 2 actually) currently does not support this
> syntax.  The
> >> main advantage the current "*" token scheme has is "**" which can match
> >> any character including '/' while "*" matches all characters except
> >> '/'.  Now, it should be possible to abstract the wildcard
> >> handling/processing so that you could plug in new wildcard handlers.
> >>
> >> Don
> >>
> >> tm jee wrote:
> >> > Just out of curiosity, the "invoice/{method}" and "{method}" pair,
> >> does
> >> the current implementation of Struts2 wildcard supports this? Looks a
> >> lot
> >> more clearer than the "invoice/*" and "{1}" pair.
> >> >
> >> >  rgds
> >> >
> >> > ----- Original Message ----
> >> > From: Bob Lee <[EMAIL PROTECTED]>
> >> > To: Struts Developers List <dev@struts.apache.org>
> >> > Sent: Wednesday, 26 July, 2006 12:01:50 PM
> >> > Subject: Re: Returning Result directly (was Re: DefaultActionMapper
> >> compatablity
> >> >
> >> > On 7/25/06, Don Brown <[EMAIL PROTECTED]> wrote:
> >> >
> >> >> <action name="invoice/*"
> >> >> class="com.eplus.app.invoice.action.InvoiceCrudAction" method="{1}">
> >> >>   <result name="list"
> >> >> type="freemarker">/template/eplus/metaDataList.ftl</result>
> >> >>   ...
> >> >> </action>
> >> >>
> >> >
> >> > Or:
> >> >
> >> > <action name="invoice/{method}"
> >> >     class="com.eplus.app.invoice.action.InvoiceCrudAction"
> >> method="{method}">
> >> >  <result name="list"
> >> type="freemarker">/template/eplus/metaDataList.ftl</result>
> >> >  ...
> >> > </action>
> >> >
> >> > Bob
> >> >
> >> > ---------------------------------------------------------------------
> >> > 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]
>
>




Reply via email to