> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Ideally, any chaining or nesting should take place behind a
> business facade. When someone starts nesting or chaining actions,
> it's an indicate that the actions are being used to implement the
> facade.
But what if the chaining is to accomplish something that is entirely
presentation-layer specific? I've always wondered about stuff like this.
Most of the Action chaining I've implemented is because the pages that
assemble an ActionForm don't collect all its information in one place: page
one supplies property X, page two supplies property Y and so on.
To illustrate: suppose you have a business method somewhere like this:
frobnicate(int frequency, int squishiness, String message)
throws CannotFrobnicateException;
Note that there are no presentation layer details here. The idea here is
that you call it, supplying all three parameters, and it either works or it
doesn't, and a whole lot of presentation-layer-agnostic business logic is
buried behind it.
Now suppose you want to hook an Action up to call this method in certain
appropriate cases, being a good Struts developer and not wanting to embed
the business logic directly into the Action. It would probably look
somewhat like this:
public ActionForward perform(...) { // or execute()...
final int squishiness = actionForm.getSquishiness();
final int frequency = actionForm.getFrequency();
// ...and so on...
// ...get the Frobnicator...
try {
frobnicator.frobnicate(frequency, squishiness, message);
} catch (final CannotFrobnicateException kaboom) {
//...handle it...
}
}
All fine and good. But now additionally suppose that the web pages that
aggregate the frequency, squishiness and message that are destined for the
frobnicator are spread out, i.e. the frequency is captured on one page, the
squishiness on another, and so on. Wouldn't it make sense to actually code
this Action differently, so that if it detects for any reason that, say, the
squishiness parameter is missing it could just forward off to the
GetSquishinessAction? E.g., taking most of the code from above:
public ActionForward perform(...) { // or execute()...
final int squishiness = actionForm.getSquishiness();
if (squishiness < 0) {
return mapping.findForward(GO_TO_GET_SQUISHINESS_ACTION);
}
final int frequency = actionForm.getFrequency();
if (frequency < 0) {
return mapping.findForward(GO_TO_GET_FREQUENCY_ACTION);
}
// ...and so on...
// ...get the Frobnicator...
try {
frobnicator.frobnicate(frequency, squishiness, message);
} catch (final CannotFrobnicateException kaboom) {
//...handle it...
}
}
Surely *this* kind of logic (forwarding to another Action when you don't
have the parameters you need because of presentation layer limitations)
isn't business logic, but is presentation logic, and surely it belongs in
Actions, whether chained or not?
My gut reaction is that this is defensive programming: if your business
method requires three parameters, then it's not really "business logic" to
make sure that the method is supplied with three parameters, right? I mean,
if your presentation layer (the web in this case) is, for whatever reason,
incapable of always supplying all three parameters at once, then shouldn't
logic like this (including Action chaining) be in place?
I'd be curious to hear what you think about this. I always get faintly
queasy when I hear the term "business logic" because I'm never really sure
what it means. :-)
Cheers,
Laird
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
