I think that is a reasonable compromise, although it will take a rewrite of the
wildcard processing. Any objections before I open an XWork ticket for this?
Don
tm jee wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
