continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@maven.org>
Subject Re: [discuss] Writing WebWork actions
Date Wed, 25 Oct 2006 19:55:56 GMT

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 <rahul.thakur.xdev@gmail.com> 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
> jesse.mcconnell@gmail.com
>


Mime
View raw message