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:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> 
> 
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
>
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=38338&messageID=76008#76008


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to