> -----Original Message-----
> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]]
> In business logic classes completely outside of the Struts
> arena.
Exactly right. This actually has some neat MVC implications if you do it
right.
I think of Struts Actions as presentation-layer-specific controllers. They:
* react to events fired by the presentation layer (browser request for
/foo/bar/showData?id=45 received)
* convert those presentation-layer-*specific* events into
presentation-layer-*agnostic* events (fire new ShowDataEvent(), or directly
invoke the ShowDataHandler, or...)
* wait for presentation-layer-agnostic "I'm done" events to burble up from
the presentation-layer-agnostic controller layer (OK, did my job; the data's
enclosed)
* update presentation layer models to reflect what the
presentation-layer-agnostic controllers have just caused to happen (shove
data into request)
* fire their own presentation-layer specific event to indicate that
they're done (return mapping.findForward(COMPLETED_SHOW_DATA))
Sometimes they also:
* do not fire presentation-layer-agnostic events at all but simply update
some piece of state that is presentation-layer-specific (e.g. update some
value in the session or do something else that affects the web container
only)
(I'm using the term "event" really loosely; it could just be a straight
method call, not a message or an EventObject/EventListener setup. For
example, an Action, converting the web-specific event
/foo/bar/showData?id=45 into its presentation-layer-agnostic equivalent,
might do either:
// This example uses JavaBeans events...
final ShowDataEvent event = new ShowDataEvent(...);
ShowDataListener listener;
for (int i = 0; i < showDataListeners; i++) {
listener = showDataListeners[i];
if (listener != null) {
showDataListeners[i].requestToSeeDataReceived(event);
}
}
...or:
// This example simply invokes methods directly,
// without any intervening JavaBeans event handling stuff
// ...retrieve showDataHandler from some storage somewhere...
showDataHandler.showData( /* various non-web parameters here */ );
At any rate, I like to at least *think* in terms of events, even if it's
often silly to implement them with the whole EventListener framework.)
Presentation-layer-agnostic controllers:
* listen for presentation-layer-agnostic events that tell them what to do
(usually one per controller).
* perform "business logic" (e.g. step 1: go get the frobnicator from the
database; step 2: engage the frobnicator; step 3: call the frobnicator's
disgorge() method; step 4: collect the results)
* update business models as a consequence of the business logic (e.g.
update the user's caturgiation record to the results obtained)
* fire a presentation-layer-agnostic "I'm done" event (could just be a
return statement, or could be an explicit event firing; usually the former)
The second layer (presentation-layer-agnostic controllers) are necessary if
you think your system will expand to have any other kind of front end on it
(that includes another web interface than the one you might be working on).
It also helps focus you on enumerating the presentation-layer-agnostic
events that you'll need to handle, regardless of how the front end allows
the end user to generate those events.
(What's weird is that a lot of GUI code (Swing, or AWT, or whatever) that
you see does the *first* part really well (ButtonListeners, ActionListeners,
WindowListeners, etc.) and omits the second part so that it's *still*
impossible (or damn hard) to untie the GUI from the application underneath.)
Returning back to earth,
Laird
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
