I'm newbee to Java and need a urgent answer. At my company we are starting java development and there is a consultor helping us. We asked him to teach us how to hard code a MVC controller, as we had used struts before. The problem is that he did the controller as a JSP page! I always thought it would not be something that one put in a JSP page. I think the controller should be a servlet but I don�t have enough knowledge to argue with him. And he�s leaving. So, technicaly speaking, how could I prove to him that he�s wrong in doing such a thing ???
Hi.. Controller is meant for getting the user input from the view and communicate with the model to reply back the view with the required information. JSP can only serve as a view.View is a presenattion layer, so JSP should be used to build the view.Whereas controller is a sort of mediator which does some important processing between view and model.So it is advisable to use servlets for the same as servlet is more of builing application logic rather than bulding presentation logic. U can visit the sun site for more Details.. Cheers Geeta
For one thing, it seems to me that having a JSP as controller makes it more difficult to serve binary data. As Geeta says, Sun's standard view of the roles of servlets and JSP always puts servlets in the controller position. Bill
Here's my 10 cents... One pricipal design goal for using Struts or any MVC architecture is to separate logic from presentation. JSP=presentation, servlet=logic. While it is technically possible to use a JSP as the controller, it really kind of silly. After all, the JSP will be compiled into a servlet anyway. What advantage is there in having the ability to short-hand markup from this controller? The only benefit I could see is that you can change the controller my simply changing the source; the server will automatically recompile it. But this could also open you up to inadvertent changes that could crash your app. The idea behind MVC is to separate form + function. The same person writing the business logic of your application may not be the same person doing your markup. And do you really want to scan through thousands of lines of JSP code to figure out why the user just bought 1000.00 units instead of 10000.0 units? There are certain other advantages to servlets that make them better candidates for the controller mechanism, but I would not get too hung up on it. If the JSP is a pure scriptlet, maybe it's not so bad. Still, I would not use a JSP as my controller. I agree with you on this. Hugh
some random thoughts that may bolster your case... i've never seen a jsp as controller, except in books, where it is used to demonstrate both that it can be done and that there is no reason to do so. as stated above jsp's should be concerned with taking business data and displaying it. i imagine that a controller jsp is hard to read, therefore hard to maintain. having the controller exist as a java class (e.g. servlet) will surely aid in maintenance and ability to easily extend.
One pragmatic reason... A Java method cannot exceed 64k. If you are using any scriptlets in your code (and even if you aren't depending on the compiler), your entire JSP will be placed in one method of a servlet when it is compiled. If you build some huge monster of a JSP controller, which is probably more likely than if you were using good OO principles in a well designed controller servlet, you may run up against the 64k wall.
Would you mind revealing the company who sent this "consultant"? I for one would think twice about employing their services again after this JSP-controller thingy. It might be OK to use JSP in order to simplify an example BUT he would've at least had to mention that this is not a recommended approach for this and that reason.