Thanks for the long opinion Ted. I agree with most of what you
discussed, which is that the Actions should be delegating to a "real"
business layer of back-end classes and methods, which can be re-applied
to a non-Struts front-end.
It's your first paragraph which I'd like to continue to discuss (and
which was in reference to my original topic of discussion):
On Fri, 2001-12-21 at 15:15, Ted Husted wrote:
Personally, I would suggest that an Action should always be used to
create whatever JavaBean helpers the view needs. The views only
responsiblity should be to render the beans. Where these beans come-from
or go-to is the controller's business.
This puts all the business logic behind Actions, and lets the
presentation layer focus on rendering the presentation without knowing
anything about the model. In the case of JavaServer Pages, it also makes
it much easier to use standard tags, like those that ship with Struts,
rather than having to write your own. This will be even more
advantageous when JSPTL is finalized.
This is where I am having a problem -- if the Action is always
responsible for creating whatever JavaBeans the View needs, then doesn't
that unnecessarily couple (tightly) the View and the Controller? If,
suddenly, the View programmers decide they not only need to render the
current user's Name, but also now need to start rendering the last five
log entries for a user (on a particular JSP page), then they have to go
back to the Action developer and ask for those additional beans to be
stuffed into the scope.
The approach I was arguing for makes it much more loosely coupled -- the
Action just does it's work, and the View just renders whatever it feels
it needs to render. Of course, it makes sense for the Action to stuff a
bean into a scope to communicate it's own activity results; however,
general "model rendering" info isn't being plugged in by the Action;
instead, the View (JSP pages) request them as they see fit.
I think this looser coupling makes for a much more manageable (less
ripple-effect) design. However, a by-product of it, is the ballooning of
custom JSP tags so that the View can get at the model, which I am having
a problem with, and for which I was soliticing alternative perspectives.
Bryan
