This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes JSP and the fly likes Calling JSP directly or not... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » JSP
Bookmark "Calling JSP directly or not..." Watch "Calling JSP directly or not..." New topic
Author

Calling JSP directly or not...

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

I have good information from someone that in a true MVC environment one should never call a JSP directly. What I mean is you should never see:
http://server/page.jsp
Rather you should see something like
http://server/page
So basically, let a servlet or a front controller or a delegate of some sort always determine the view. While part of me understands this approach, I still don't fully understand what this accomplishes.
I am just wondering what everyone else thinks about this.


GenRocket - Experts at Building Test Data
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
One of the main benefits of going through an intermediate controller is that it can greatly reduce the complexity of the JSPs. Each JSP can be designed solely to cater for displaying results for a single condition, in the assumption that whatever was requested was valid and successful, and all the needed data has been populated.
If you call a JSP directly (from an input form, for example), the JSP has to include code for checking the validity of the supplied form fields, for performing the action and determining any output, and (worst of all) has to include code for what to do if the parameters were invalid or the requested operation was inappropriate, or something went wrong. You'd probably also need to put lots of "if not null" checks on everything used in the JSP, in case it had been called out of sequence or after an incomplete process.
Isn't it much nicer to check the requested action and parameters in a single place, (and pass on to "oops.jsp" if there was something wrong), then perform the action, and pass on to either "itworked.jsp" or "itfailed.jsp" ?


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Ken Robinson
Ranch Hand

Joined: Dec 23, 2003
Posts: 101
My belief is that in a true MVC environment, the JSP should be the View, that is only a dispaly template.
Now, I have had instances where the View did not require anything to be valid. Say you have a basic Create New Record (say a user) page. There may not be anything the page needs to display except the template itself. Instead of using just an HTML page, I use JSP since once the page is submitted, I like to come back to the same page and show errors. Using JSTL's <req: p arameter> tag, I always place the current value of the parameter in the parameter (this is blank the first time, but unchanged upon submission and forward to the same URL). If I goto Login.jsp, hit submit and the Servlet decides the login is invalid, I forward to Login.jsp. The second time around the error and user id are displayed. The first time no logic was needed to get these values as they didn't exist.
While I think it is perfectly fine to go directly to a JSP page in this instance (instead of having a 'dummy' servlet), I usually register the JSP as a servlet in web.xml and map it to a more standard URL, never with the .JSP as part of the URL. If all of my other URLs are .HTML or .DO, that is what I map this JSP to. Remember, JSPs are subclasses of Servlet and can be treated much like any other servlet.
[ December 29, 2003: Message edited by: Kenneth Robinson ]
Andres Gonzalez
Ranch Hand

Joined: Nov 27, 2001
Posts: 1561
Originally posted by Gregg Bolinger:
I have good information from someone that in a true MVC environment one should never call a JSP directly. What I mean is you should never see:
http://server/page.jsp
Rather you should see something like
http://server/page
So basically, let a servlet or a front controller or a delegate of some sort always determine the view. While part of me understands this approach, I still don't fully understand what this accomplishes.
I am just wondering what everyone else thinks about this.

Most of the times, when you receive a request, you have to do some checkings before delegating the request to a particular view (check if user is authorized to access that page, check log in status, etc). This is the reason, IMO, you should always delegate your request to a controller (It doesn't necessarily need to be a servlet, it can even be a JSP without any presentation code. Bit weird, but I've seen cases of that).
We tend to think that our web application will have the flow of events in which we program it. But that never happens. A user can bookmark a JSP once he's done some stuff (signing in, etc) and come back to the same page the next day. If we access our jsp's directly, we'll end up having lots of java code/validation in our jsp's, and we all know this is not a good approach.
I've read an article once that explained why JSPs should be declared under the WEB-INF directory, so it should never be accessed directly. One of the reasons was security.


I'm not going to be a Rock Star. I'm going to be a LEGEND! --Freddie Mercury
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Thanks Andres. That's good to know. The only issue I was having with this was the summy servlets I would have to create for a few static views. But you helped me solve that problem in the other thread.
Thanks again.
 
 
subject: Calling JSP directly or not...