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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
