Bryan Field-Elliot wrote: > This is where I am having a problem -- if the Action is always > responsible for creating whatever JavaBeans the View needs, then doesn't > that unnecessarily couple (tightly) the View and the Controller?
Personally, I advocate the Layers pattern for web applications, rather than the Smalltalk MVC paradigm. In a layered application, the controller stands between the view and model. The view can interact with the controller, and the controller can interact with the model, but the view does not interact with the model, since they are not on adjacent layers. In this approach, the model itself is also layered, so that there is a business layer (API), an interface layer (JDBC), and a resource layer (DBMS). I would say that the controller provides the information and the view renders it. If the view needs more information, then yes, the controller API needs to be extended, so that it provides the correct and complete information. In a layered application, that is the controller's job. Personally, I like to give objects (or people) a job, and then let them do it. > suddenly, the View programmers decide they not only need to render the > current user's Name, but also now need to start rendering the last five > log entries for a user (on a particular JSP page), then they have to go > back to the Action developer and ask for those additional beans to be > stuffed into the scope. If the View programmers are smart enough to write custom tags, then they should also be able to work on their own Actions. Most often, the View designers are not trained in writing custom tags, so it then becomes a matter of whether the Java developers are writing custom tags or JavaBeans that can be exposed by standard tag extensions. If the customization is made to the JavaBeans, rather than the tags, then the information is available to any presentation system that can access a JavaBean, not just JSPs in a Web application. General purpose tags, like those in the Struts distribution, and also be used to access the new JavaBeans, so that the view designers do not have yet another tag to deal with. It's possible that in your scenario things might need to be moved up a rung. Perhaps some of what is now in the Actions belong in business layer classes to be handled by the current "Action developers". Anyone clever enought to write a custom tag should be able to handle an Action, if there is a business layer API to back it up. It's possible that much of what is now going into custom tags could be just as easily moved into an Action. > The approach I was arguing for makes it much more loosely coupled -- the > Action just does it's work, and the View just renders whatever it feels > it needs to render. I would venture that it actually increases coupling. Instead of the view being coupled to the controller and the controller being coupled to the model, all three are coupled to each other. Any change to the model affects all three layers. Smalltalk MVC got away with this sort of thing, but that strategy doesn't work as well for remote applications that connect with distributed data systems. > Of course, it makes sense for the Action to stuff a > bean into a scope to communicate it's own activity results; however, > general "model rendering" info isn't being plugged in by the Action; > instead, the View (JSP pages) request them as they see fit. I would say that it is the Action's job to provide the View with whatever data it needs. As far as the View is concerned, the JavaBeans in the servlet contexts are the model. This way real changes to the real Model do not need to affect the View directly. The Action can be an adapter between the business-tier data systems and the View. This reduces overall coupling, since signficant changes can take place in the Model without the View knowing the difference. > I think this looser coupling makes for a much more manageable (less > ripple-effect) design. However, a by-product of it, is the ballooning of > custom JSP tags so that the View can get at the model, which I am having > a problem with, and for which I was soliticing alternative perspectives. It seems to me that code that accesses the model is being duplicated between the custom tags and the Actions, and that would become a maintenance burden over time. The tags are being tightly bound to the business or resource tiers, which violates the Layers pattern. A symptom of this is the code ballooning. Also, from a practical standpoint, the services (like Jasper) that render the JSP custom tags write some god-awful code. The less you put into tag extensions, or scriplets, or any kind of programming in the View, the better. When the effort goes into JavaBeans that are passed to view, the resulting code is not only more efficient, but these beans become available to any presentation system in any environment that may come down the pipeline. For example, it is very easy to turn a JavaBean into an XML document that another system in the enterprise can use. Case in point: several of the Struts tags now access the framework's "model", and we have found that to be problematic. Accordingly, we have recently added a ContextHelper JavaBean to the framework. We're in the process of moving code that accessed the framework model into the ContextHelper. When we are done, the tags will get whatever they need from the ContextHelper instead of from the Struts model directly. As a result, we will have decoupled the tag extensions from a particular ActionServlet implementation. We could start using multiple ActionServlets, or entirely different controllers, so long as they pass a ContextHelper along to the presentation layer. This initiative also decouples Struts from the tag extensions, and makes it easy to use with other presentation systems, like Velocity templates. Since the ContextHelper provides the same utility as the tags, any presentation system that can access a JavaBean can lookup up hyperlinks and localized messages, and other services the framework provides. Moving forward, this will also reduce maintenance, since maintaining the ContextHelper, a plain Java class, is much simpler than routing around in custom tag code, which can be difficult to factor properly. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
