Re: [discuss] Writing WebWork actions

[Jason van Zyl]

On 25 Oct 06, at 3:46 PM 25 Oct 06, Jesse McConnell wrote:
I also bounced this off of a couple other people over the last day  
or to..

there seems to be a general consensus from folks that I talked to that
its a good idea to try and group all the CRUD (Create, Read, Update,
Delete) actions on objects grouped into a single action.


Why? I think that's a bad idea. An action in the traditional sense is  
atomic and are strung together to create activities. I think jamming  
these things together is bad. I think jamming fundamentally different  
actions together is bad. We used to do this in Turbine where one Java  
class could perform any number of actions and it was a maintenance  
nightmare.

With individual actions classes it will always pertain to that action  
and it can be modified without having to worry about side effects. If  
the class is doing more then one thing it's not really an action  
anymore.

Are you only talking about webwork actions here? For me I've always  
wanted a declarative way to map the web junk to the real actions of  
the application. And if I were to wire together a series of actions  
into a activity using a workflow tool I would definitely never put  
the logic of more then one action into one class. Having the logic  
contained in a single class means that you can always operate on the  
class in a very known way. As soon as you have something more then  
that you entirely lose the power of abstraction. Does it do one  
thing? Does it do two things? Do I need to create a method to tell me  
what it does so I can generalize it? All bad things. It does one  
thing, only one thing and will always only do one thing.

On that note, it would be good to standardize the method names as
well, perhaps to:

public String add() {}
public String update() {}
public String view() {}
public String remove() {}

Then we would have the decision of the xwork.xml which could have
actions for each of these methods on the class, like

<action name="addFoo" class="continuum-foo" method="add">

or on the jsp's we could just use the shortcut of <ww:form  
action="foo!add">

how does this grab folks?   I think this is a valuable step in things
since it will give us a chance to audit all of the actions, improve
the -webapp project for contributors...and -webapp is a great place
for people to start with continuum...and it will also serve as a good
swift kick towards finishing off the testing work that emmanuel will
be committing soon.

jesse




On 10/25/06, Rahul Thakur <[EMAIL PROTECTED]> wrote:
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>





--
jesse mcconnell
[EMAIL PROTECTED]