Discussions

J2EE patterns: Customizing a single view for multiple entrypoints (using MVC)

  1. The ViewCustomization bean is a POJO with getter/setter methods that are used for tweaking view related stuff on the JSP page. Using MVC, each entry point has a controller
    that instantiates and populates the bean and passes it on to the JSP.


    Controller1
    ===========

    ViewCustomization bean = new ViewCustomization();
    bean.setNameBoxStyle("width:200px;");
    bean.enableSaveButton(true);
    request.setAttribute("bean", bean);
    request.getRequestDispatcher("view.jsp").forward(request, response);

    Controller2
    ===========

    ViewCustomization bean = new ViewCustomization();
    bean.setNameBoxStyle("width:100px;");
    bean.enableSaveButton(false);
    request.setAttribute("bean", bean);
    request.getRequestDispatcher("view.jsp").forward(request, response);

    View
    ====
    <body>
    <jsp:usebean id="viewBean" scope="request"/>
    <input type="text" style="<%= viewBean.getNameBoxStyle() %>">
    <input type="button" <%= viewBean.enableSave()?"disabled":"" %> value="Save">
    </body>



    The ViewCustomization bean is tied tightly to the JSP and so
    changes in JSP would have to be reflected in the bean (depending on how tightly you use the bean to customize the JSP). However the trade-off of having just one view for multiple entry points is a huge maintainence savings.
  2. With this you are adding a tie between the Controller and the ViewCustomization bean, and you have already noted that the ViewCustomization bean is tightly tied to the JSP, so you are noticeably increasing the ties between the Controller and the View.

    It would be better if the View could decide for itself which entry route was used.
    For example if the JSP created the ViewCustomization bean passing it the request context, and the bean could determine for itself the entry route and set the parameters appropriately.

    This pulls the Controller out of that loop again, maintaining the View/Controller seperation, while allowing more re-use of the JSP at the expense of a more complex ViewCustomization bean.

    Brian.
  3. It would be better if the View could decide for itself which entry route was used.

    This is wrong, as you are then having business logic in the view which kind of defeats the whole purpose of the MVC pattern, but I do agree with you about the said disadvantage you've given :)

    Thomas, Enterprise PHP developer
  4. > It would be better if the View could decide for itself which entry route was used.This is wrong, as you are then having business logic in the view which kind of defeats the whole purpose of the MVC pattern, but I do agree with you about the said disadvantage you've given :)Thomas, Enterprise PHP developer

    Logic in the view should only be concerned width layout decisions. The controller should set flags in the model so has to let the view decides which parts to show and how. No "Business logic" embedded in the view just piloted layout decisions.