Return-Path: 
 <continuum-dev-return-5329-apmail-maven-continuum-dev-archive=maven.apache.org@maven.apache.org>
Delivered-To: apmail-maven-continuum-dev-archive@www.apache.org
Received: (qmail 27253 invoked from network); 26 Oct 2006 04:11:29 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 26 Oct 2006 04:11:29 -0000
Received: (qmail 43896 invoked by uid 500); 25 Oct 2006 19:11:41 -0000
Delivered-To: apmail-maven-continuum-dev-archive@maven.apache.org
Received: (qmail 43876 invoked by uid 500); 25 Oct 2006 19:11:41 -0000
Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:continuum-dev-help@maven.apache.org>
List-Unsubscribe: <mailto:continuum-dev-unsubscribe@maven.apache.org>
List-Post: <mailto:continuum-dev@maven.apache.org>
List-Id: <continuum-dev.maven.apache.org>
Reply-To: continuum-dev@maven.apache.org
Delivered-To: mailing list continuum-dev@maven.apache.org
Received: (qmail 43865 invoked by uid 99); 25 Oct 2006 19:11:40 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Oct 2006 12:11:40 -0700
X-ASF-Spam-Status: No, hits=1.9 required=10.0
	tests=DNS_FROM_RFC_ABUSE,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: 210.54.141.245 is neither permitted
 nor denied by domain of rahul.thakur.xdev@gmail.com)
Received: from [210.54.141.245] (HELO fep01.xtra.co.nz) (210.54.141.245)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Oct 2006 12:11:27 -0700
Received: from nonec03d6244ff ([222.155.132.170]) by fep01.xtra.co.nz
          with ESMTP
          id <20061025191056.NJE23450.fep01.xtra.co.nz@nonec03d6244ff>
          for <continuum-dev@maven.apache.org>;
          Thu, 26 Oct 2006 08:10:56 +1300
Message-ID: <000901c6f869$4dfa6d70$4001a8c0@nonec03d6244ff>
From: "Rahul Thakur" <rahul.thakur.xdev@gmail.com>
To: <continuum-dev@maven.apache.org>
Subject: [discuss] Writing WebWork actions
Date: Thu, 26 Oct 2006 08:09:46 +1300
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="Windows-1252";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Virus-Checked: Checked by ClamAV on apache.org

Jesse and I tossed some ideas about having some sort of consistent 
patterns for writing Webwork actions in Continuum. Below is a transcript 
from yesterday's chat. We wanted to bring this up for discussion and 
would be great to have any ideas/suggestions other might have.

Cheers,
Rahul

<snip>

<rahul> hello there
<jesse> heya
<rahul> just had some ideas that I wanted to jot down here quickly
<jesse> shoot
<rahul> ok, here goes (and pls bear with me if I have to go check on 
breakfast :)  )
<rahul> ok, i have quick run thru of the patterns/conventions that we 
are using in our internal framework
<rahul> starting with xwork.xml , the equivalent config.xml is broken up 
into 3 files
<rahul> 1) defines components  - lets call it components.xml
<rahul> 2) defines pages (that are composite of layout templates + 
components) , lets call it pages.xml
<rahul> 3)  defanes action patch mappings  (page flow) - lets call it 
mappings.xml
<rahul> 1) follows convention that all component names are prefixed with 
'component.' - ex:  'component.group.notifier.edit'
<rahul> 2)  has page names prefixed with 'page.' - ex: 
'page.notifier.summary'
<rahul> action mappings are pretty much similar to what is there in 
xwork.xml currently - i will come to method name later
<rahul> i am just rattling off here with notes  :) - you will have to 
help me see these elements can/do map to WW or can be made to map
<rahul> Components are supported by component handlers - that prepare 
the display of and help render components - The java classes are 
suffixed XXXComponentHandler. I have come across this with notifiers
<rahul> Action classes are ManageXXXXAction - that process requests 
for - edit/update/delete. I think the create one is different (I will 
have to check again)
<rahul> methods in ManageXXXAction follow convention (like I 
mentioned) - processEditRequest, processUpdateRequest, 
processDeleteRequest
<rahul> and validations are performed in the actions themselves (but I 
like what WW does from validation.xmls)
<rahul> for 'result' returned from the action - 'success' and 'failure' 
are by default available and another convention is 'failure.system' for 
any internal errors
<rahul> other results can map to the action request - 'success.edit' , 
'success.delete' - I am adding this from my end :)
<rahul> so, what do you reckon?
<rahul> sorry i haven't been able to put it in an email yet
<jesse> reading latest
<jesse> I have actually been kicking around something brett mentioned a 
while back about generating actions automatically for CRUD things
<jesse> and I talked to patrick lightbody and he was a fan of all CRUD 
operations being in one object
<jesse> which was where I had started out
<jesse> which seemed to be what your detailing up here
<jesse> so I think I would do ProjectNotifierAction and 
GroupNotifierAction
<jesse> with associated add/edit/view/remove methods
<rahul> cool! is it possible to structure xwork.xml like I said above?
<jesse> not sure about the need of the success.edit stuff
<jesse> you could do that by having one action and using the 
action|method syntax in the jsp
<jesse> or just have multiple actions referencing the same class and 
using the method="x" attribute
<rahul> ah, you are right :)
<rahul> ok, i gotta run in a minute. do you still want to put this on 
the list?
<jesse> its probably worth it
<rahul> ok, mind if I just stick in the transcript with a  little 
background?
<jesse> you have my authorization :P
<rahul> aye cap'tn  :)
<rahul> thanks! - i gotta run for work now
<rahul> cheers
<jesse> laters

</snip>