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