Re: Fwd: and

[Ted Husted <te...@husted.com>]

Ted Husted wrote [to Struts-DEV]:
 > When a page says
 >
 > <logic:forward forward="welcome"/>
 >
 > it's not deciding where to go. It's asking the controller "where's the
 > welcome forward", and the controller returns the appropriate URI. The
 > html:link tag does the same thing.
 >
 > If you want to talk strict MVC, the taglibs are rife with these type
 > of "voilations". (And I use the term loosely.) Most of the linking
 > tags can take a page parameter, which is a system URI. In a strict MVC
 > environment, the pages shouldn't know anything at all about the system
 > URIs.
 >
 > While we try to encourage best practices, Struts was never a strict
 > MVC/Model 2 framework. We have lots and lots of tags that help people
 > cross over from the Model 1 side. Scuttling these would just make
 > migrating more difficult.
 >
 > IMHO, the role of Struts is to provide a practical, standards-based
 > Model 2 framework that *encourages* best practices. We shouldn't be
 > preaching MVC for MVC's sake.
 >
 > MVC is a useful paradigm, but, honestly, most of us are not really
 > using a textbook MVC architechture. Most of us are using the layers
 > pattern. When you combine layers with the Struts controller and
 > aglibs, it looks a lot like MVC. But more often than not, to describe
 > what a lot of us are doing, you need to stretch the MVC paradigm a
 > country mile.
 >
 > -Ted.


<name withheld> wrote:
 > Ted:
 >
 > I am interested in this [Struts-DEV] thread, but I do not want to
 > burden the entire distribution with my amateur thoughts.
 >
 > Before I start I need to say that I am enjoying your book a great
 > deal. So far I have found your book and Sue Spielman's book as my
 > favorite ones. As a matter of fact we have purchased copies of your
 > book for our entire development staff. (30 folks).
 >
 > I think what you are saying is that the view often does do the work of
 > the controller. In fact historically we often see the view merged with
 > the controller. Epicentric does exactly the same thing. I do not think
 > Swing does this, I think Swing is much more pure in this regard.
 >
 > What I get from your thoughts this is the following inference on my
 > part:
 >
 > It is not so bad that this is true, as it might make a project's time
 > to market faster. And here is my big inference: It would be a true
 > violation if we were to move the control screen flow move to the
 > model, at least it would be a real violation to incorporate a ton of
 > 'struts' knowledge into the model. Because this would make the
 > model too dependent upon the current implementation of the framework
 > omponents of the and thus make maintained difficult.


The underlying problem is that most applications have more than three
layers. Not everything fits squarely in the MVC triumvirate.

 From my perspective, there is the model that represents the problem
domain. Here, we decide that we need to collect this data to provide
this result. This model can often be reduced to a database schema.

There is also a model that represents the "solution domain". Here, we
decide that we need to collect this data on screen 17 and that data on
screen 23.

This second model might be called the workflow controller. It's an
essential part of the client's perception of the application. In
practice, a significant part of development involves meeting a
business client's workflow requirements. Business clients can be very
particular as to what data is collected on which screens in what order.

The better part of the workflow model has little to do with the
presentation medium. There may be some differences in terms of whether a
screen can be modal or not, which can affect your choice of controls,
but other than that, a workflow doesn't always need to know whether
it's a web application or not.

Struts is not itself a workflow controller. The forward mechanism can
support a workflow controller, but Struts itself does not include a
workflow engine. Struts can map workflow tokens, like "success",
"failure", or "logon" to system paths (URIs), but it doesn't include a
heuristic mechanism to decide what token to emit. (Most often, the
workflow logic is embedded in the Action and maintained by hand.)

The presentation screens are tied to the workflow model. The screen
needs to know what workflow elements it can access and what data fields
it can capture or present. (The display requirements.) It doesn't need
to anything about the system URIs, but it does need to know whether it
can access "logon" or "storeAccount".

Strut's job is to map workflow tokens like "logon" or "storeAccount" to
system paths. This way a screen can deal in logical workflow terms and
avoid embedding (and worse duplicating) system paths.

Ideally, the presentation controller (Struts) should provide the screen
everything it needs to know in order to render itself. The page
shouldn't make any actual "decisions", just output what it is given to
output. (Which is good, since HTML pages have enough to worry about
already.)

Sometimes, we fall short of this ideal just to reduce the HTML
maintenance. Some pages can have dozens of possible states and trying
to maintain a dozen different variations of a display can be a cure
worse than the disease. But, even then, Struts can reduce the decision
making to simple boolean tests on JavaBean properties, so that the
display isn't "deciding" as much as it is following directions.

In the original case, it would be my position that since these logic
tags don't use system paths, but use the paths provided to them by the
controller, they do not violation MVC. Rather, they embrace it! The
controller provides the path for the forward; the page simply ouputs
whatever it is given.

When a workflow token for an action comes in, Strut's other job is to
provide a place where you can access the workflow and data models.
After interacting with the models, the Action interprets the outcome,
selects a workflow token, and uses that token to select a system path
(e.g. ActionForward).

Of course, ideally, the workflow model should be selecting the token,
so that Struts can just map it to the appropriate system path.

We've got all sorts of stuff for the data model, and I'm sure everything
has been used in one Struts application or the other. There is also a
lot of stuff for the workflow model, but much of it doesn't seem to be
used in Struts application right now. As web applications become more
complex, that's certain to change.

-Ted.



-- 
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org