Rick Reumann wrote:
I was just replying to a post about keeping your Actions clean and
doing the business logic in other classes.
One thing I didn't bring up, though, because I'm not sure how 'best
practice' it is, is the concept of passing your ActionForm and
sometimes the HttpServletRequest off to another class for some
processing. I'm doing that a bit in this app I'm currently working on
and I'm liking it.
I have something like FormPersister interface with 2 methods -
loadBO2form and saveBOFromForm which I use to copy the properties, then
I store all implementators of this interface to a small factory and in
the Action I have something like this:
String objectTypeParam = request.getParam("objecttype"); ... (some
validation if the the param is not null etc.)
Than by this type I search the propriate implementator and just use one
of the both methods depending on what I'm doing in this action - show or
save of the object.
The real problem is that these loadBO2form and saveBOFromForm can throw
a lot of different eceptions - for validation, domain exceptions (object
doesn't exist - for example was deleted by other user, because I use
optimistic locking) and in the end seems to me that I doesn't helps me a
lot (I mean this architecture with FormPersister). And I doubt it will
live very long ... the logic is too much spread ...makes the actions too
"lean" ..
The above is quite simple but sometimes there are some other things
that have to be done that aren't alway orthodox... ie, maybe having
to build more than one VO from a form, or maybe some logic looking at
certain form/request parameters to dictate some slightly altered
service class method to call. All of this stuff tends to staring bloat
the Action class which is supposed to mainly be a controller. I've
started now playing around with pushing some of this off to another
class and the Action then becomes mostly just responsible for 1)
validation 2) saving any success or error messages 3) fowarding
So what happens is the Action looks like...
//EmployeeAction
execute(...) or dispatchmethod() {
EmployeForm empForm = (EmployeeForm)form;
//validate form, if success proceed..
boolean success = EmployeeActionHelper.updateEmployee( empForm,
request );
//messages set up based on success or failure
}
I think that approriate pattern here is chain of responsibility - for
example: validation->persistence->triggered actions (email sending etc)
And great will be if such chain can be configured by xml file ...
Anyway, I'm just babbling:)
I don't think so, we just discuss practices and may be some of them are
at least nice to share.
For example I have a base classes that derive from Action and
DispatchAction and they store the GoF (ActionMapping mapping, ActionForm
form, HttpServletRequest req, HttpServletResponse resp) in wraper class
taht I save in a thread local, so latteron I use it to access them
instead to pass them all around. (may be this is not very nice ... I
still not proved it works very fine ... :-( )
Regards
Borislav
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
