The Controller Mystery ?????

Discussions

Web tier: servlets, JSP, Web frameworks: The Controller Mystery ?????

  1. The Controller Mystery ????? (10 messages)

    Hi all,

    Can any one explain me what is the trade off involved in going in for a JSP to perform the controllers role, as compared to the traditional method of using a servlet as a controller.

    One point is, it is very very easy for the developer to develop the jsp pageg as compared to the servlet, and coding time is also going to go down on choosing jsp as a controller.

    Is there any real advantage to go in for a servlet to perform the controllers function ?

    What is not possible in a JSP controller that is possible in a Servler.

    I do agree that internally JSP is converted into a servlet but in the traditional MVC architecture why is a servlet given the controllers role ?

    Can any one throw some light on this ?

    Regards,
    D. Prashant.

    Threaded Messages (10)

  2. JSP pages are designed to output markup, and they fit the MVC view role perfectly. I don't know why you would think using JSP as a controller would be any easier than a servlet. Controllers do not output markup. They perform normal Java code tasks: update the model, respond to various events, etc. You literally can't write a controller in JSP. The only thing you can do is embed controller code right inside the view, which is bad in many ways. Read any basic tutorial on MVC or web development to see why.

    Gal
  3. The Controller Mystery ?????[ Go to top ]

    Hi Prashant,

    For a discussion of the implementation issues surrounding this, take a look at the documentation for the Front Controller design pattern:

    http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html

    There is a brief discussion of the Servlet Front Strategy and JSP Front Strategy solutions to this common problem, and some information on the trade-offs involved.

    As Gal mentioned, while it is possible to use a JSP as a controller, in most cases this involves crossing lines of responsibility within the MVC design.

    There is (I believe, I don't have the book handy ATM) a further discussion of this in the Core J2EE Patterns book as well.

    Regards,

    Brian Neal
    BEA Systems, Inc.
  4. The Controller Mystery ?????[ Go to top ]

    \Brian\

    http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html

    There is a brief discussion of the Servlet Front Strategy and JSP Front Strategy solutions to this common problem, and some information on the trade-offs involved.

    As Gal mentioned, while it is possible to use a JSP as a controller, in most cases this involves crossing lines of responsibility within the MVC design.
    \Brian\

    I think this misses the original poster's point. While the link you provided shows why it's bad to have a controller that also spits out markup (e.g. mixing controller and view information in one physical place), I don't think that's what the poster is after.

    It's perfectly reasonable to write your controller as a JSP, especially during development, because there's less boilerplate required in writing & compiling JSPs compared to making a dedicated servlet. You end up with a "controlling JSP" which only acts as a controller, and emits no information on its own.

    The benefit is that the JSP auto-compiles as you make changes, plus as I mentioned there's less boilerplate. This makes it easier to make rapid changes.

    Remember - a JSP essentially _is_ a servlet.

        -Mike
  5. The Controller Mystery ?????[ Go to top ]

    Hi Mike,

    Thanks for your comments. With regards to missing the point, I disagree that I missed it, but I think thats better answered by the poster. The point I took away from the post was:

    - What is the tradeoff involved in using a JSP as a controller rather than a servlet,

    and,

    - Is there any real advantage to go in for a servlet controller to perform the controllers function?

    With regards to the article, I think the following quote sums it up pretty well:

    "Though semantically equivalent, the Servlet Front Strategy is preferred to the JSP Front Strategy. Since the controller handles processing that is not specifically related to display formatting, it is a mismatch to implement this component as a JSP page.

    Implementing the controller as a JSP page is clearly not preferred for another reason: It requires a software developer to work with a page of markup in order to modify request handling logic. Thus, a software developer will typically find the JSP Front Strategy more cumbersome when completing the cycle of coding, compilation, testing, and debugging. Example 7.15 is an example of the JSP Front Strategy."

    As regards your comment about boilerplate, which was also one of the original posters concerns, the above quote offers a perspective on that as well. Boilerplate is a function of everything from coding style to development tool support as well.

    And yes, while a JSP is a servlet in implementation terms, in development they are 2 very different things.

    In the end, I believe the issue of deciding between a Servlet and a JSP controller is fairly clear---the Servlet is a better choice.

    Best,

    Brian Neal
    BEA Systems, Inc.
  6. The Controller Mystery ?????[ Go to top ]

    \Brian\
    "Though semantically equivalent, the Servlet Front Strategy is preferred to the JSP Front Strategy. Since the controller handles processing that is not specifically related to display formatting, it is a mismatch to implement this component as a JSP page. "
    \Brian\

    I see the point here, but there's nothing to back it up. The point is right up front in your quote - "semantically equivalent". I'll go futher and say they're (almost) structurally equivalent as well.

    And remember - servlets can output display formatting just as well as a JSP component can. It just so happens that it's slightly easier in a JSP.

    In short - the potential for mis-use is just as real in a servlet and as in a JSP.

    \Neal\
    Implementing the controller as a JSP page is clearly not preferred for another reason: It requires a software developer to work with a page of markup in order to modify request handling logic. Thus, a software developer will typically find the JSP Front Strategy more cumbersome when completing the cycle of coding, compilation, testing, and debugging. Example 7.15 is an example of the JSP Front Strategy."
    \Neal\

    This is completely off-point. I can easily write a JSP which does _exactly_ what a servlet controller does, without the JSP emitting or containing any markup on its own.

    \Brian\
    And yes, while a JSP is a servlet in implementation terms, in development they are 2 very different things.
    \Brian\

    I completely disagree. A JSP is a servlet that's easier to develop, and who's source is in a different language. In fact, a JSP is defined in terms of a servlet.

    \Brian\
    In the end, I believe the issue of deciding between a Servlet and a JSP controller is fairly clear---the Servlet is a better choice.
    \Brian\

    I'd like to see a specific, concrete reason why that's so.

        -Mike
  7. The Controller Mystery ?????[ Go to top ]

    I really don't understand what you guys are talking about. How would you write an MVC controller object in jsp? A controller doesn't output anything, what would the JSP look like? Like this: ?
    controller.jsp:
    <%
    my code...
    %>
    end of file

    If so, how is that better than a Servlet? It seems a lot worse to me. JSP pages are designed to output markup. If they don't output markup you gain nothing, and just move a chunk of your Java code into a file with a different syntax. None-jsp developers will have a harder time maintaining the code, you can't extend the controller in the normal Java sense, even having member variables in the controller requires the use of a different type of syntax. I can't see why anybody would want this. Maybe I'm missing your point and we mean different things by "controller"?

    Gal
  8. The Controller Mystery ?????[ Go to top ]

    \Gal\
    I really don't understand what you guys are talking about. How would you write an MVC controller object in jsp? A controller doesn't output anything, what would the JSP look like? Like this: ?
    controller.jsp:
    <%
    my code...
    %>
    end of file
    \Gal\

    That's exactly right. And what's wrong with that?

    \Gal\
    If so, how is that better than a Servlet? It seems a lot worse to me. JSP pages are designed to output markup. If they don't output markup you gain nothing, and just move a chunk of your Java code into a file with a different syntax.

    None-jsp developers will have a harder time maintaining the code...
    \Gal\

    The advantage is that changes auto-compile, and there's less code.

    As for none-JSP developers: I don't think it takes all that much to pick up JSP. I've yet to find a developer who had a hard time with it.

    \Gal\
    ... you can't extend the controller in the normal Java sense, even having member variables in the controller requires the use of a different type of syntax. I can't see why anybody would want this. Maybe I'm missing your point and we mean different things by "controller"?
    \Gal\

    Yes, I agree it's different. There are some advantages I've found to using JSP-based controllers, but it's not always a win. If the complexity went very high I might very well use a light servlet layer with a framework of controller classes. But for simple and medium-weight work, a JSP controller works just as well for a servlet. If you don't like it - OK, then use servlets. But an awful lot of people know JSPs, so the "differentness" of it doesn't matter, and it's slightly easier to code and maintain moderate controllers in JSP than in servlets. That's all.

    And I still object to people saying using a JSP as a controller is always wrong - I've yet to see a clear cut reason why it's wrong. Unless, again, you're talking about a very complex application where other techniques might manage the complexity better.

        -Mike
  9. The Controller Mystery ?????[ Go to top ]

    Mike,

    This discussion is getting noisy :) If you want to continue it with me offline, drop me an email at brian dot neal at bea dot com.

    Model 1 vs. Model 2 is something that has been discussed in many forums. Here is a take on it that I personally agree with:

    The Web Tier

    There are thousands of others, and numerous books, articles, and other resources available on this topic. Everyone is entitled to their opinion. My opinion, based on my experience, is that the servlet is a superior choice to the JSP for a controller in all but the simplest of applications.

    Cheers,

    Brian Neal
    BEA Systems, Inc.
  10. The Controller Mystery ?????[ Go to top ]

    \Neal\
    Model 1 vs. Model 2 is something that has been discussed in many forums. Here is a take on it that I personally agree with:

    The Web Tier

    There are thousands of others, and numerous books, articles, and other resources available on this topic. Everyone is entitled to their opinion. My opinion, based on my experience, is that the servlet is a superior choice to the JSP for a controller in all but the simplest of applications.
    \Neal\

    I think I understand your point of view. What you may be missing is that you can implement a full-blown model 2 system using JSPs as controller(s). And those JSP controllers will behave exactly like servlet controllers, and not violate MVC in anyway. I've done it both ways - with servlets as controllers, and with JSP as controllers (and also both). From a design standpoint they work exactly the same.

    As you say, much of this is opinion, and also preference. But there's no technical reason why it can't be done using JSPs. It may seem a bit odd to use a JSP in this manner, but it's rock solid technically. And it has a positive aspect that it slightly lowers the barriers of entry for people new to the technology - a controller written JSP is a bit easier to create, understand, and configure in an app server than a servlet based one.

    In short - it's not "wrong" (as the Sun article puts it) to use a JSP as your controller. You're only violating MVC if your controller (be it a servlet or a JSP, it can happen in either) does more than a controller should.

         -Mike
  11. The Controller Mystery ?????[ Go to top ]

    Mike,

    I don't think neither approach is wrong. I personally don't see any advantage to the JSP approach, and some minor disadvantages (harder to extend/reuse, doesn't work as well with all IDEs, requires more work as the controller becomes more complicated as a part of the development process, can't seperate code into methods as easily). The biggest reason, I think, is simply that JSP are allmost allways used as view components, and it would simply confuse me to have business logic there. If I was looking for the business logic in someone else's code, JSP pages would be the last place I look.
    I agree none of these are clear-cut reasons not to use JSP as a controller. I also understand from your post that there are some other factors that I did not consider. I don't agree that there is a lot of boilerplate code involved in using servlets (if you have a common base class for servlets, the boilerplate code is exactly 4 lines as opposed to two in JSP). The entry cost of a JSP or Servlet are the same for me, but I suppose newbies may find it easier to deal with JSPs. I'd rather educate them on how to write Servlets and where to put business logic (e.g, not in JSPs :) but in some projects that may be impossible.

    Keep all these factors in mind and choose whatever you want.

    Cheers,
    Gal