continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse McConnell" <jesse.mcconn...@gmail.com>
Subject Re: [discuss] Writing WebWork actions
Date Wed, 25 Oct 2006 20:05:39 GMT
that actually segways nicely into a topic brett brought up a long time
back where it would be really nice to not even write the majority of
actions, but to just annotate them somewhere and have a plugin like
the cdc just generate the webwork actions themselves..  I was actually
kicking that around a bit yesterday.

good points, all of them.

one thing that I don't like about the combined into one object is you
end up having a score of unused fields for operations like delete.

anyone else?

jesse



On 10/25/06, Jason van Zyl <jason@maven.org> wrote:
>
> 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
> >
>
>


-- 
jesse mcconnell
jesse.mcconnell@gmail.com

Mime
View raw message