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 20:28:14 GMT

On 25 Oct 06, at 4:05 PM 25 Oct 06, Jesse McConnell wrote:

> 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.
>

You need actions, but they are application actions. What Summit  
attempted to allow was for you to write your application actions  
regardless of the view. Then in a declarative way the parameters you  
wanted from the webview were extracted and directed to the  
application action. I never documented Summit and it did Velocity so  
I wasn't going to foist in on everyone but I still maintain it is  
possible to purely have configuration for moving parameters from a  
view to the application for execution. Internationalization,  
exception handling and reporting are important and I went down the  
wrong path there in Summit but I would say shoot for not writing  
Webwork actions at all. The plexus-action component is currently  
inappropriate but I am still for writing all the actions as simple  
objects with the idea of creating activities and workflows.

You simply need a mapping mechanism you move things from the webview.  
I used OGNL expression in Summit to extract the information but  
something fast could be used. You can't annotate the actions because  
they may be used by different views where the person writing the only  
really needs to know what to send to the action so you can't mix  
those concerns. So for a single page, or multi-page diaglog with a  
web user you collect all the relevant information extracting the  
parameters you need from each request/response and then pass that all  
along to the application. The webwork actions should do absolutely  
zero application logic. I know most actions just grab some  
information and then call the application but app logic always creeps  
in which is bad because it means that using a web services interface  
I'm going to get different behavior. I definitely think eliminating  
the WW action usage would be a good thing and turn purely into an  
information mapping layer. My attempt failed with Summit but I know  
it's possible.

Something like:

public interface Action
{
	ActionResult execute( Map parameters )
		throws ActionExecutionException;
}

Would mostly do the trick as from any view the parameters can always  
come in a Map and you can do efficient things like create Map  
adapters so you can use request parameters directly without having to  
push them all into a Map. When the action executes you can always  
clearly see the result so this works manually nicely, and if you tie  
this up into a workflow the engine can inspect the action results  
along the path of execution to control the flow of the activity.

Create a good application interface with a rich model and then create  
a layer to extract the information from the view to used in the  
execution of an application action, actions, or activity.

Jason.

> 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