[EMAIL PROTECTED] wrote:
> Isn't it against the mvc philosophy to put navigation code (e.g. control)
> into a tag (e.g. view) ?

Generally, it's the view's job to capture user gestures, and the
controller's job to interpret them. Presentation code that says "next" 
or "prev" is a gesture. Code that says "next.jsp" or "prev.jsp" is 
interpreting a gesture.

So far this discussion has been about constructing a dynamic view that
presents the buttons needed to capture the user gestures: they want to
do this or they want to do that. A core problem is that a HTML
button's label and its value are the same, so we have to use hidden
fields, and other smoke-and-mirror techniques, to get buttons with the
same labels to represent different gestures. 

In real life, we still need to use logic to program the view. Otherwise,
we would have to a different page for every combination of application
state. One form for input. Another for update. Of course, this would
violate the MVC prime directive: optimize for long-term maintenance
(or "change is the only constant" ;0). 

The cutting edge is whether the view "knows" anything about other views.
When this happens, changes start to cascade between pages, and
maintenance is not optimal. 

So long as all links pass through ActionForwards (forward="") and
mappings (*.do or /do/*), then the flow is being determined by
controller 
layer, and could be reconfigured without changing the presentation code. 

Thus, the MVC gods are appeased ;-)

-Ted.

Reply via email to