My viewpoints are a little more simplistic. There is a lot of gray area between the definition of presentation layer and business logic. There has to be some impact or you couldn't drive the business layer from the presentation layer.
We do the best we can to minimize the impact of one upon the other. If something is clear, i.e. the shape of the buttons is presentation layer, the layout of the tables is business layer, you put it in the correct space. If something is gray, i.e. frobnicatation, you understand it the best you can and break it up in a logical way. Lastly you use the tools available, with action chaining being one of the tools, to implement your analysis. If your analysis works best with action chaining, you are a winner, if it works without it, great too. Edgar :-) -----Original Message----- From: Nelson, Laird [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 12, 2002 10:23 AM To: 'Struts Developers List' Subject: RE: Action chaining: (was - Re: Why are people up on Struts) > -----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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
