The notion of a "view helper" object that is inserted by your Action into the appropriate context is something that has been around for a while. In my opinion making the Controller portion or worst the Model portion aware of the View breaks the whole idea of MVC. You are right in that most of the times, there is logic that is needed in the View to do things like what you stated. However that logic is View centric only. In other words, presentation logic.
There are several mechanisms to implement presentation logic. Struts gives you plenty of objects that help you deal with it. The Tag libraries that Struts gives you coupled with the new JSTL tags, should be more the sufficient to tackle almost all sorts of presentation logic that is unique to a specific presentation. If a case comes up when either tag usage is becoming overly complex, or there is a lot of as you call it "Big Ball of Mud", then that indicates problems in the overall design of the application. This can come from two reasons. One, a lot of what should be application logic is seeping through to the view, which indicates that the model portion of the application is not well factored or designed. Two, the usage of HTML itself in the design of the pages, is not properly used, which is usually an indication to me whenever I see a framed site or a site that relies heavily in client side scripting. In my opinion, frames should not be the basis of a front end design. Almost every web application that I've come across that uses frames has done so because of improper front end design and a general lack of knowledge of simple Web principles and design guidelines. HTTP and the Web are simple, that's what makes it so popular. So why make it over complicated? I suggest reading up on Usability design for the web, especially Jakob Nielsen's works. Even though I don't agree with everything that Jakob and other usability experts preach, there are valuable lessons and just plain common sense ideas that can be gained from learning about web usability. Now, what to do if even after you do have a good front end design and usability guidelines established, and your view is still becoming overly complex? Going back to what I stated in the beginning of this email, you can design a View helper type object, which can take the form of a custom tag or a JavaBean or a combination of the two. This view helper would know how to render a tab for example, or a menu. But those decisions and logic would happen inside this object, without much if any work done, in say the Action class. Just instantiate it, pass it some objects, and stuff it into one of the scopes. If you are doing anything more then that, then you're doing too much. Again the key here is that it is a _View_ Helper. As you can probably tell, I don't like frames. There are very few use cases when frames truly make sense. In my opinion Frames should be your very last alternative to a UI problem and only after you exhaust all other design possibilities, should it then be considered. Sometimes this isn't a easy decision because it usually indicates an overall problem with the usability design of a web application. I'm sure there will be a lot of people that disagree with this view. And that's just too bad for them :) To end, the idea of a ViewContext object as you describe it is probably flawed in thinking. There are times where you do need more then Tags to handle your presentation logic. Those cases however should be the exception and not the rule. Best of luck, John > -----Original Message----- > From: Vikram B Kumar [mailto:[EMAIL PROTECTED] > Sent: Sunday, June 15, 2003 1:50 PM > To: Struts Users Mailing List > Subject: Making Controllers Aware of Views' Structural Information > > 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] This communication is intended for the use of the individual(s) or entity it was addressed to and may contain confidential and/or privileged information. If the reader of this transmission is not the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is prohibited. If you receive this communication in error, please notify the sender immediately and delete this communication from your system(s) to which it was sent and/or replicated to. (c) 2003 Sapiens Americas Corp. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
