Making Controllers Aware of Views' Structural Information

[Vikram B Kumar <vb...@yahoo.com>]

We have spent much thoughts on MVC, and very good J2EE web frameworks,
Struts being the foremost, have been developed as a result. We have best
practices and clean way of generating views.

Yet, IMHO, the V part of MVC, especially managing views, has not been
bestowed with the same amount of attention.

Here is one example:

I am consulting for a company which has a large web application. The
application has been organized around different products of the company.

On the server-side, we use Struts and similar web application frameworks.
Many features have been added to the application and the M and C portions of
the web application are under control and I think we have done a good job
there.

However the view itself has de-evolved into a Big Ball of Mud.

The following:

  1. Tab highlighting based on the product an user is currently viewing.
  2. TOC highlighting based on the feature of the product an user is
currently viewing.
  3. Frames management.
  4. Context-sensitive help.

are working fine but have been implemented using intricate gestalt of
JavaScript/Cookie/Inter-frame communication.

Adding to the complexity is the abstraction between various product
applications.

We are trying to develop a new view and I realise that trying to manage all
the complexity of the view's navigational structure in client-side will
result in the same BBOM.

It seems logical that some kind of server-side framework can best aid in
facilitating a smooth navigational experience.

Given that, I need a mechanism to represent the environmental information of
the view component that sends a request to the controller and that of view
component that will display the response to the user.

I call this the ViewContext.

The principal responsibility of such a ViewContext is to provide contextual
and structural information above a view component.

This ViewContext may be from the source of a request or for a destination.

The main uses are:

1. Peripheral info such as context-sensitive help, Tab/Context highlighting
can be easily managed.
2. Minimise inter-frame communication.
3. Ability to place views in different contexts with just configuration
change.

The View Context itself can be customized per-application basis.

I view this as an invaluable scheme to bring some kind of order into the
view chaos.

I proposed this to some of my colleagues. They understand the idea but some
are principally opposed to this as this one brings the context of view into
Controllers. What they fail to understand is that currently the fundamental
navigational flow is etched into View->Controller->View interaction and the
views make lot of assumptions and hard-coded bindings with other views.

ViewContext makes the Controllers "context-aware" and helps flexible
contracts between views.

I checked JavaServer Faces and it too lacks such kind of view context
support.

Your thoughts? Your experiences?



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