You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Jason Carreira <fo...@opensymphony.com> on 2006/07/25 23:31:37 UTC
Re: Returning Result directly (was Re: DefaultActionMapper
compatablity
Ugh, not this again... Doesn't anyone else reuse their actions and map them in several different ways?
>
> I personally would like to see XWork enhanced to
> support action methods
> returning Result instances directly, however we would
> have to thoroughly think
> through the consequences.
>
> Reasons for:
> - Better security
> - Easier, more explicit
> - Results will probably be defined as annotations
> soon, so why not just return
> he Result directly?
> - Allows non-annotation apps to drastically
> minimize config
> - Supports more complex results
> Reasons against:
> - The Action interface really loses most of its
> meaning
> - ActionSupport could no longer extend Action
> - XWork internals would need modification since many
> places expect a result code
> - Supporting the return of Result, String, and
> Object might be confusing for
> ew developers
> - Current Results would need some improvements to
> make them easier to use
> better constructors, default location names/patterns,
> etc)
>
> Again, all things considered, I'd really like to see
> us add the ability to
> return Results directly as I think it just makes
> things easier. The ability to
> separate JSP paths from Java code, IMO, is way
> overrated and years of its
> practice hasn't shown the additional complexity is
> really worth it. For those
> that prefer the old style, they would still have that
> option.
>
> Don
>
> >
> > -t
> >
> > On Jul 25, 2006, at 4:11 PM, Ted Husted wrote:
> >
> >> On 7/25/06, Jason Carreira
> <fo...@opensymphony.com> wrote:
> >>> @Action to mark it as an Action method?
> >>
> >> Stripes uses the annontation @DefaultHandler where
> we would configure
> >> a default action, which might imply the annotation
> @Handler for what
> >> we are talking about here.
> >>
> >> *
> http://stripes.mc4j.org/confluence/display/stripes/Ann
> otation+Reference
> >>
> >> -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
>
>
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=38338&messageID=75718#75718
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by Bob Lee <cr...@crazybob.org>.
On 7/26/06, Jason Carreira <fo...@opensymphony.com> wrote:
>
> I understand that there are different ways to skin the cat, but what if I
> want to reuse my actions in different contexts? What if I want to call my
> action from a JBPM workflow? Do I need to subclass it to override the result
> that's returned?
It's my understanding that the current approach wouldn't go away. I'd prefer
to stick to one approach, but if one approach can't meet everyone's needs...
Then again, any new approach would have to provide a lot of value over the
current approach. People keep talking about modeling results using
annotations, but I've yet to see an approach I like. I'm perfectly aware
that my "abstract result method" suggestion is a bad idea, but it's the only
decent annotation-based approach I can come up with, and I'm trying to get
the conversation started and think outside the box.
I don't understand this huge backlash against XML in the Java community. XML
> has its place. XML is really good at representing hierarchical structured
> data. Building up that hierarchy in Java code isn't nearly as intuitive or
> understandable (to me). There's definitely ways to over-do it, but I think
> it's shifted too far back the other way.
I agree with this, but Spring still puts too much information in XML (and
moving the configuration into Java in the way they've done is not the
solution). XML is better than Java for declaration, but we should resist
embedding too much logic. XML is a lot harder to debug and refactor than
Java. :)
Bob
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by Ted Husted <hu...@apache.org>.
See also
* http://issues.apache.org/struts/browse/WW-1393
* http://forums.opensymphony.com/thread.jspa?messageID=45763닃
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Returning Result directly (was Re: DefaultActionMapper
compatablity
Posted by Patrick Lightbody <fo...@opensymphony.com>.
With the understanding that this is an issue that needs to be treated carefully to avoid confusion, I think we should really give some serious thought to this.
As someone who _has_ actually done annotation-based result mapping (I have setups with no xwork.xml - I can explain more if requested), I can say it still isn't pretty, especially when it comes to redirects and I want to parameterize some data in the redirect.
I'm not saying I'm +1 on it (yet), but I think that Tim has a lot of good insight here as someone who has worked on (and created) a framework that works in this way. Similiarly, Don (and all Struts 1.x developers) have done the same thing. We shouldn't toss out their words so quickly.
I'd like to see an official proposal of how this would work, including how we'd deal with subclassing ActionSupport (ie: ActionSupport wouldn't be able to provide a method signature for both execute methods). One option is to get rid of the need to subclass and push all the logic in ActionSupport in to parts of the API that Bob is working on.
Patrick
> Being able to return Result instances from Actions
> doesn't
> necessarily mean the lack of reuse of Results. This
> is equivalent to
> saying that because it's Java code you can't reuse
> it. I didn't
> realize that XML was the solution to lack of reuse in
> OO ;)
>
> Seriously though, it's not uncommon in Stripes where
> multiple actions
> have the same resolution to simply factor that out to
> a single method
> or even a constant sometimes. Given your CRUD
> example there's no
> reason you couldn't setup a crud Action with multiple
> methods for add
> (), update() delete() etc. that also had abstract
> methods for the
> list-page result and the details-page result. Then
> not only would
> you have reuse of your Result information, but you'd
> have all your
> action/navigational information in one place and
> completely
> standardized across CRUD beans.
>
> The approach may not be for everybody, I understand.
> But sometimes
> f you let go of the XML and start doing things in
> code, you start to
> see different approaches that achieve the same goals.
> I'm sorry if
> hat sounds condescending. All I'm trying to do is
> make you think
> outside of the box you are in as a WW core developer
> (obviously, I
> have my own box, but that's another story...)
>
> -t
>
>
>
> On Jul 25, 2006, at 11:22 PM, Jason Carreira wrote:
>
> >> Could you give an example how multiple mappings
> for a
> >> single action is
> >> used with common CRUD actions?
> >>
> >> Don
> >
> > Ok, here's what our Invoice CRUD action mappings
> look like:
> >
> > <action name="listInvoice"
> >
> class="com.eplus.app.invoice.action.InvoiceCrudAction"
> method="list">
> > <interceptor-ref name="listStack"/>
> > <result name="CRUD-list"
> type="freemarker">/template/eplus/
> > metaDataList.ftl</result>
> > </action>
> > <action name="editInvoice"
> >
> class="com.eplus.app.invoice.action.InvoiceCrudAction"
> >
> > <interceptor-ref name="editStack"/>
> > </action>
> > <action name="saveInvoice"
> >
> class="com.eplus.app.invoice.action.InvoiceCrudAction"
> method="save">
> > <interceptor-ref name="crudStack"/>
> > </action>
> > <action name="deleteInvoice"
> >
> class="com.eplus.app.invoice.action.InvoiceCrudAction"
>
> method="delete">
> <interceptor-ref name="crudStack"/>
> </action>
> >
> >
> >
> > A better example of reusing the same action with
> the same method
> > several times is our DomainObjectLister. We're
> still working out
> > the entity meta-data we've been building, so I
> foresee this
> > continuing to evolve, but it's pretty simple
> already. In the future
> > you'll just need to configure it with the domain
> type.
> >
> > <action name="getVendorRelationships"
> >
> class="com.eplus.lib.web.action.DomainObjectLister">
> > <param
> >
> name="domainClass">com.eplus.biz.catalog.mgmt.model.Ve
> ndorRelationship
> > </param>
> > <param
> name="visibleFields">vendor.name</param>
> > <param name="idField">id</param>
> > <param
> name="sortColumn">vendor.name</param>
> > <result name="success"
> type="freemarker">/template/
> > eplus/lists/domainObjectTable.ftl</result>
> > </action>
> > <action name="getBuyerCatalogs"
> >
> class="com.eplus.lib.web.action.DomainObjectLister">
> > <param
> >
> name="domainClass">com.eplus.biz.catalog.mgmt.model.Bu
> yerCatalog</
> > param>
> > <param
> name="visibleFields">name,description</param>
> > <param name="idField">id</param>
> > <param name="sortColumn">name</param>
> > <result name="success"
> type="freemarker">/template/
> > eplus/lists/domainObjectTable.ftl</result>
> > </action>
> >
> ------------------------------------------------------
> ---------------
> > Posted via Jive Forums
> > http://forums.opensymphony.com/thread.jspa?
> > threadID=38338&messageID=75787#75787
> >
> >
> >
> ------------------------------------------------------
> ---------------
> > 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
>
>
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=38338&messageID=76008#76008
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by Tim Fennell <tf...@tfenne.com>.
On Jul 26, 2006, at 11:00 AM, Jason Carreira wrote:
> I understand that there are different ways to skin the cat, but
> what if I want to reuse my actions in different contexts? What if I
> want to call my action from a JBPM workflow? Do I need to subclass
> it to override the result that's returned?
Yes, that is exactly what you'd do. You'd use a mechanism that every
java developer is already intimately familiar with - subclassing.
But let me ask you this: out of all WW2 actions that exist (not just
in your project, but everywhere) how many do you think get reused in
a non-web context? 10%? 5%? I know XWork is designed to allow
this, but is it a common case? Would you not be better off if it
took less work to write up the majority of actions that are web-only,
and then through subclassing or some other similar setup, could
extend and override the behaviour for other contexts?
I agree that XML has it's place, but used for configuration data that
doesn't change at runtime, it has several downsides:
- it is less easily compiled/validated
- you naturally have to have linkage between XML and code, leading
to repetition
- /new/ developers have to learn your XML dialect to become
productive
> On a side note, have you seen the stuff where people try to do code
> versions of the configuration for Spring? It looks horrible, even
> when they've gone to the effort to try to develop DSL-type helper
> methods.
No I haven't, but I can imagine. I'm not a big spring user. But
even here, I've argued before that I'd much rather see injection
sites declared using annotations in code (e.g. @Dependency
("someServiceName/Type")) than in XML. That keeps all the
information about the class in one place. But I think actual service
configuration makes sense in XML (ok, honestly I'd prefer YAML, but
that's another story), and doing this in Java would likely lead to an
unreadable mess.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Returning Result directly (was Re: DefaultActionMapper
compatablity
Posted by Jason Carreira <fo...@opensymphony.com>.
> Being able to return Result instances from Actions
> doesn't
> necessarily mean the lack of reuse of Results. This
> is equivalent to
> saying that because it's Java code you can't reuse
> it. I didn't
> realize that XML was the solution to lack of reuse in
> OO ;)
>
> Seriously though, it's not uncommon in Stripes where
> multiple actions
> have the same resolution to simply factor that out to
> a single method
> or even a constant sometimes. Given your CRUD
> example there's no
> reason you couldn't setup a crud Action with multiple
> methods for add
> (), update() delete() etc. that also had abstract
> methods for the
> list-page result and the details-page result. Then
> not only would
> you have reuse of your Result information, but you'd
> have all your
> action/navigational information in one place and
> completely
> standardized across CRUD beans.
>
> The approach may not be for everybody, I understand.
> But sometimes
> f you let go of the XML and start doing things in
> code, you start to
> see different approaches that achieve the same goals.
> I'm sorry if
> hat sounds condescending. All I'm trying to do is
> make you think
> outside of the box you are in as a WW core developer
> (obviously, I
> have my own box, but that's another story...)
>
> -t
>
>
I understand that there are different ways to skin the cat, but what if I want to reuse my actions in different contexts? What if I want to call my action from a JBPM workflow? Do I need to subclass it to override the result that's returned?
On a side note, have you seen the stuff where people try to do code versions of the configuration for Spring? It looks horrible, even when they've gone to the effort to try to develop DSL-type helper methods.
I don't understand this huge backlash against XML in the Java community. XML has its place. XML is really good at representing hierarchical structured data. Building up that hierarchy in Java code isn't nearly as intuitive or understandable (to me). There's definitely ways to over-do it, but I think it's shifted too far back the other way.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=38338&messageID=75940#75940
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by Tim Fennell <tf...@tfenne.com>.
Being able to return Result instances from Actions doesn't
necessarily mean the lack of reuse of Results. This is equivalent to
saying that because it's Java code you can't reuse it. I didn't
realize that XML was the solution to lack of reuse in OO ;)
Seriously though, it's not uncommon in Stripes where multiple actions
have the same resolution to simply factor that out to a single method
or even a constant sometimes. Given your CRUD example there's no
reason you couldn't setup a crud Action with multiple methods for add
(), update() delete() etc. that also had abstract methods for the
list-page result and the details-page result. Then not only would
you have reuse of your Result information, but you'd have all your
action/navigational information in one place and completely
standardized across CRUD beans.
The approach may not be for everybody, I understand. But sometimes
if you let go of the XML and start doing things in code, you start to
see different approaches that achieve the same goals. I'm sorry if
that sounds condescending. All I'm trying to do is make you think
outside of the box you are in as a WW core developer (obviously, I
have my own box, but that's another story...)
-t
On Jul 25, 2006, at 11:22 PM, Jason Carreira wrote:
>> Could you give an example how multiple mappings for a
>> single action is
>> used with common CRUD actions?
>>
>> Don
>
> Ok, here's what our Invoice CRUD action mappings look like:
>
> <action name="listInvoice"
> class="com.eplus.app.invoice.action.InvoiceCrudAction" method="list">
> <interceptor-ref name="listStack"/>
> <result name="CRUD-list" type="freemarker">/template/eplus/
> metaDataList.ftl</result>
> </action>
> <action name="editInvoice"
> class="com.eplus.app.invoice.action.InvoiceCrudAction">
> <interceptor-ref name="editStack"/>
> </action>
> <action name="saveInvoice"
> class="com.eplus.app.invoice.action.InvoiceCrudAction" method="save">
> <interceptor-ref name="crudStack"/>
> </action>
> <action name="deleteInvoice"
> class="com.eplus.app.invoice.action.InvoiceCrudAction"
> method="delete">
> <interceptor-ref name="crudStack"/>
> </action>
>
>
>
> A better example of reusing the same action with the same method
> several times is our DomainObjectLister. We're still working out
> the entity meta-data we've been building, so I foresee this
> continuing to evolve, but it's pretty simple already. In the future
> you'll just need to configure it with the domain type.
>
> <action name="getVendorRelationships"
> class="com.eplus.lib.web.action.DomainObjectLister">
> <param
> name="domainClass">com.eplus.biz.catalog.mgmt.model.VendorRelationship
> </param>
> <param name="visibleFields">vendor.name</param>
> <param name="idField">id</param>
> <param name="sortColumn">vendor.name</param>
> <result name="success" type="freemarker">/template/
> eplus/lists/domainObjectTable.ftl</result>
> </action>
> <action name="getBuyerCatalogs"
> class="com.eplus.lib.web.action.DomainObjectLister">
> <param
> name="domainClass">com.eplus.biz.catalog.mgmt.model.BuyerCatalog</
> param>
> <param name="visibleFields">name,description</param>
> <param name="idField">id</param>
> <param name="sortColumn">name</param>
> <result name="success" type="freemarker">/template/
> eplus/lists/domainObjectTable.ftl</result>
> </action>
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?
> threadID=38338&messageID=75787#75787
>
>
> ---------------------------------------------------------------------
> 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
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by Bob Lee <cr...@crazybob.org>.
It doesn't, but I think it should. (Yes, Ted, I should do it then. ;))
Bob
On 7/25/06, tm jee <tm...@yahoo.co.uk> 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 <cr...@crazybob.org>
> To: Struts Developers List <de...@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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
>
>
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by Don Brown <mr...@twdata.org>.
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 <cr...@crazybob.org>
> To: Struts Developers List <de...@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 <mr...@twdata.org> 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 <mr...@twdata.org> 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 <cr...@crazybob.org>
>>>>> To: Struts Developers List <de...@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 <mr...@twdata.org> 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: 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
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by tm jee <tm...@yahoo.co.uk>.
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 <cr...@crazybob.org>
To: Struts Developers List <de...@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 <mr...@twdata.org> 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 <mr...@twdata.org> 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 <cr...@crazybob.org>
> >> > To: Struts Developers List <de...@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 <mr...@twdata.org> 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: 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
>
>
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by Bob Lee <cr...@crazybob.org>.
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 <mr...@twdata.org> 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 <mr...@twdata.org> 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 <cr...@crazybob.org>
> >> > To: Struts Developers List <de...@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 <mr...@twdata.org> 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: 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
>
>
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by Don Brown <mr...@twdata.org>.
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 <mr...@twdata.org> 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 <cr...@crazybob.org>
>> > To: Struts Developers List <de...@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 <mr...@twdata.org> 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: 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
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by Bob Lee <cr...@crazybob.org>.
{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 <mr...@twdata.org> 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 <cr...@crazybob.org>
> > To: Struts Developers List <de...@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 <mr...@twdata.org> 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: 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
>
>
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by Don Brown <mr...@twdata.org>.
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 <cr...@crazybob.org>
> To: Struts Developers List <de...@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 <mr...@twdata.org> 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: 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
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by tm jee <tm...@yahoo.co.uk>.
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 <cr...@crazybob.org>
To: Struts Developers List <de...@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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by Bob Lee <cr...@crazybob.org>.
On 7/25/06, Don Brown <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by Don Brown <mr...@twdata.org>.
Jason Carreira wrote:
>> Could you give an example how multiple mappings for a
>> single action is
>> used with common CRUD actions?
>>
>> Don
>>
>
> Ok, here's what our Invoice CRUD action mappings look like:
>
> <action name="listInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction" method="list">
> <interceptor-ref name="listStack"/>
> <result name="CRUD-list" type="freemarker">/template/eplus/metaDataList.ftl</result>
> </action>
> <action name="editInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction">
> <interceptor-ref name="editStack"/>
> </action>
> <action name="saveInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction" method="save">
> <interceptor-ref name="crudStack"/>
> </action>
> <action name="deleteInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction" method="delete">
> <interceptor-ref name="crudStack"/>
> </action>
>
For this case, I would rather construct a single interceptor stack that
could handle all requests so I could do:
<action name="invoice/*"
class="com.eplus.app.invoice.action.InvoiceCrudAction" method="{1}">
<result name="list"
type="freemarker">/template/eplus/metaDataList.ftl</result>
...
</action>
This also has the advantage of having cleaner URL's, IMO. Furthermore,
you could use "*/*" and match all your crud actions in one shot.
> A better example of reusing the same action with the same method several times is our DomainObjectLister. We're still working out the entity meta-data we've been building, so I foresee this continuing to evolve, but it's pretty simple already. In the future you'll just need to configure it with the domain type.
>
> <action name="getVendorRelationships" class="com.eplus.lib.web.action.DomainObjectLister">
> <param name="domainClass">com.eplus.biz.catalog.mgmt.model.VendorRelationship</param>
> <param name="visibleFields">vendor.name</param>
> <param name="idField">id</param>
> <param name="sortColumn">vendor.name</param>
> <result name="success" type="freemarker">/template/eplus/lists/domainObjectTable.ftl</result>
> </action>
> <action name="getBuyerCatalogs" class="com.eplus.lib.web.action.DomainObjectLister">
> <param name="domainClass">com.eplus.biz.catalog.mgmt.model.BuyerCatalog</param>
> <param name="visibleFields">name,description</param>
> <param name="idField">id</param>
> <param name="sortColumn">name</param>
> <result name="success" type="freemarker">/template/eplus/lists/domainObjectTable.ftl</result>
> </action>
>
In this case, you would definitely want to use the XML configuration
option. One you start creating generic, parameterized Actions, the XML
plays a much larger part in the process. However, I'm not sure those
still wouldn't be the edge cases.
Don
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=38338&messageID=75787#75787
>
>
> ---------------------------------------------------------------------
> 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
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by tm jee <tm...@yahoo.co.uk>.
This might not be related, but I like the way Jason does it, and its the way I'd like to do it as well, especailly since I learn that foo!bar is going to get deprecated.
----- Original Message ----
From: Jason Carreira <fo...@opensymphony.com>
To: dev@struts.apache.org
Sent: Wednesday, 26 July, 2006 11:22:41 AM
Subject: Re: Returning Result directly (was Re: DefaultActionMapper compatablity
> Could you give an example how multiple mappings for a
> single action is
> used with common CRUD actions?
>
> Don
Ok, here's what our Invoice CRUD action mappings look like:
<action name="listInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction" method="list">
<interceptor-ref name="listStack"/>
<result name="CRUD-list" type="freemarker">/template/eplus/metaDataList.ftl</result>
</action>
<action name="editInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction">
<interceptor-ref name="editStack"/>
</action>
<action name="saveInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction" method="save">
<interceptor-ref name="crudStack"/>
</action>
<action name="deleteInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction" method="delete">
<interceptor-ref name="crudStack"/>
</action>
A better example of reusing the same action with the same method several times is our DomainObjectLister. We're still working out the entity meta-data we've been building, so I foresee this continuing to evolve, but it's pretty simple already. In the future you'll just need to configure it with the domain type.
<action name="getVendorRelationships" class="com.eplus.lib.web.action.DomainObjectLister">
<param name="domainClass">com.eplus.biz.catalog.mgmt.model.VendorRelationship</param>
<param name="visibleFields">vendor.name</param>
<param name="idField">id</param>
<param name="sortColumn">vendor.name</param>
<result name="success" type="freemarker">/template/eplus/lists/domainObjectTable.ftl</result>
</action>
<action name="getBuyerCatalogs" class="com.eplus.lib.web.action.DomainObjectLister">
<param name="domainClass">com.eplus.biz.catalog.mgmt.model.BuyerCatalog</param>
<param name="visibleFields">name,description</param>
<param name="idField">id</param>
<param name="sortColumn">name</param>
<result name="success" type="freemarker">/template/eplus/lists/domainObjectTable.ftl</result>
</action>
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=38338&messageID=75787#75787
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Returning Result directly (was Re: DefaultActionMapper
compatablity
Posted by Jason Carreira <fo...@opensymphony.com>.
> Could you give an example how multiple mappings for a
> single action is
> used with common CRUD actions?
>
> Don
Ok, here's what our Invoice CRUD action mappings look like:
<action name="listInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction" method="list">
<interceptor-ref name="listStack"/>
<result name="CRUD-list" type="freemarker">/template/eplus/metaDataList.ftl</result>
</action>
<action name="editInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction">
<interceptor-ref name="editStack"/>
</action>
<action name="saveInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction" method="save">
<interceptor-ref name="crudStack"/>
</action>
<action name="deleteInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction" method="delete">
<interceptor-ref name="crudStack"/>
</action>
A better example of reusing the same action with the same method several times is our DomainObjectLister. We're still working out the entity meta-data we've been building, so I foresee this continuing to evolve, but it's pretty simple already. In the future you'll just need to configure it with the domain type.
<action name="getVendorRelationships" class="com.eplus.lib.web.action.DomainObjectLister">
<param name="domainClass">com.eplus.biz.catalog.mgmt.model.VendorRelationship</param>
<param name="visibleFields">vendor.name</param>
<param name="idField">id</param>
<param name="sortColumn">vendor.name</param>
<result name="success" type="freemarker">/template/eplus/lists/domainObjectTable.ftl</result>
</action>
<action name="getBuyerCatalogs" class="com.eplus.lib.web.action.DomainObjectLister">
<param name="domainClass">com.eplus.biz.catalog.mgmt.model.BuyerCatalog</param>
<param name="visibleFields">name,description</param>
<param name="idField">id</param>
<param name="sortColumn">name</param>
<result name="success" type="freemarker">/template/eplus/lists/domainObjectTable.ftl</result>
</action>
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=38338&messageID=75787#75787
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by Don Brown <mr...@twdata.org>.
Could you give an example how multiple mappings for a single action is
used with common CRUD actions?
Don
Jason Carreira wrote:
>> I'm sure some people do, but the question is in what
>> percentages? I have done
>> it, but only a couple of times, perhaps representing
>> 2-3% of my actions. Since
>> the XML configuration way is still an option, I think
>> orienting the framework to
>> make the more common things easier, yet still
>> allowing more complex
>> configuration, is the best approach.
>>
>> Don
>>
>
> Since at least 50% of an app ends up being CRUD operations and we should make it easy to have a reusable CRUD / list / search framework... like the one we've built at work... then I'd say probably 50% of the action configs will be reused action classes. We've been harvesting more and more reusability in our app as we keep finding opportunities.
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=38338&messageID=75779#75779
>
>
> ---------------------------------------------------------------------
> 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
Re: Returning Result directly (was Re: DefaultActionMapper
compatablity
Posted by Jason Carreira <fo...@opensymphony.com>.
> I'm sure some people do, but the question is in what
> percentages? I have done
> it, but only a couple of times, perhaps representing
> 2-3% of my actions. Since
> the XML configuration way is still an option, I think
> orienting the framework to
> make the more common things easier, yet still
> allowing more complex
> configuration, is the best approach.
>
> Don
Since at least 50% of an app ends up being CRUD operations and we should make it easy to have a reusable CRUD / list / search framework... like the one we've built at work... then I'd say probably 50% of the action configs will be reused action classes. We've been harvesting more and more reusability in our app as we keep finding opportunities.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=38338&messageID=75779#75779
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Returning Result directly (was Re: DefaultActionMapper compatablity
Posted by Don Brown <mr...@twdata.org>.
I'm sure some people do, but the question is in what percentages? I have done
it, but only a couple of times, perhaps representing 2-3% of my actions. Since
the XML configuration way is still an option, I think orienting the framework to
make the more common things easier, yet still allowing more complex
configuration, is the best approach.
Don
Jason Carreira wrote:
> Ugh, not this again... Doesn't anyone else reuse their actions and map them in several different ways?
>
>> I personally would like to see XWork enhanced to
>> support action methods
>> returning Result instances directly, however we would
>> have to thoroughly think
>> through the consequences.
>>
>> Reasons for:
>> - Better security
>> - Easier, more explicit
>> - Results will probably be defined as annotations
>> soon, so why not just return
>> he Result directly?
>> - Allows non-annotation apps to drastically
>> minimize config
>> - Supports more complex results
>> Reasons against:
>> - The Action interface really loses most of its
>> meaning
>> - ActionSupport could no longer extend Action
>> - XWork internals would need modification since many
>> places expect a result code
>> - Supporting the return of Result, String, and
>> Object might be confusing for
>> ew developers
>> - Current Results would need some improvements to
>> make them easier to use
>> better constructors, default location names/patterns,
>> etc)
>>
>> Again, all things considered, I'd really like to see
>> us add the ability to
>> return Results directly as I think it just makes
>> things easier. The ability to
>> separate JSP paths from Java code, IMO, is way
>> overrated and years of its
>> practice hasn't shown the additional complexity is
>> really worth it. For those
>> that prefer the old style, they would still have that
>> option.
>>
>> Don
>>
>>> -t
>>>
>>> On Jul 25, 2006, at 4:11 PM, Ted Husted wrote:
>>>
>>>> On 7/25/06, Jason Carreira
>> <fo...@opensymphony.com> wrote:
>>>>> @Action to mark it as an Action method?
>>>> Stripes uses the annontation @DefaultHandler where
>> we would configure
>>>> a default action, which might imply the annotation
>> @Handler for what
>>>> we are talking about here.
>>>>
>>>> *
>> http://stripes.mc4j.org/confluence/display/stripes/Ann
>> otation+Reference
>>>> -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
>>
>>
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=38338&messageID=75718#75718
>
>
> ---------------------------------------------------------------------
> 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