Thomas Oellrich wrote:
> Hello all,
>
> I'm building a Web application based on the Model 2 architecture advocated
> by folks like Craig. I'm wondering how you guys handle requests for JSP
> pages where no previous action was executed. Are these requests also directed
> to the controller servlet or do you let the JSP pages handle these requests
> directly? If so, I guess these JSP pages need to include authentification.
>
In my apps, I let the user start at a JSP page (for example index.jsp). The
<jsp:useBean> declaration will create beans for me that don't exist, and I have
craftily defined my beans to configure themselves with appropriate default values in
such a case.
For security, I've taken two different approaches:
* In servlet containers that do not support the 2.2 servlet API, I add a little
scriptlet that checks the user's session for existence of a LoginBean, and
does a <jsp:forward> to the login page if it is missing. The bean would be
missing on a new session, if the user's old session timed out (and a new one
was created), or after a logoff (where I invalidate the session).
* Now that the 2.2 servlet spec lets you define security constraints for
URL paths (in much the same way you can configure protection on
sets of static content in a web server), I'm going to let the container
worry about security -- I will never have to write a login page or check
scriptlet again; all I need to worry about is configuring the servlet
container on how to look up usernames and roles.
> Another issue arises when the JSP page contains a list which needs to be
> populated from a database. Is it a good a idea to let the view retrieve data from
> the model directly?
>
My usual approach is to do the database lookups in action procedures managed by the
controller servlet, which formats the results as beans stored in the appropriate
context before forwarding to an appropriate JSP page to display them. In no
circumstances do I do any JDBC calls from within the JSP page. This approach has
several advantages:
* This minimizes the amount of time that a JDBC connection
(from a connection pool) is utilized, so it maximizes the
number of users that can share a given number of
connections.
* My beans provide an object oriented model of the
underlying data, and I can change the physical database
layout without changing the JSP pages that depend
on this model.
* In fact, I can do more radical things (like move a users list
from a database to a directory server) without modifying
the JSP pages, as long as the logical interface is the same.
To enforce this, I generally define a Java interface for each
business object, and a third tier of my app provides
implementation classes. The JSP pages deal only in terms
of the interfaces.
* I can use the same data in more than one page (view), without
replicating the retrieval logic.
For lists, there are two basic scenarios -- the list is short enough to fit in
memory, or it's not. If it is, I just use a Vector or some other collection class
to store the multiple responses. If it's not, there are various strategies to tell
your action procedure which results to capture. For example, you can look at the
URL sent in by many search engines and see that they are basically asking "select
all the responses that match this criteria, then skip the first X results and return
me the next Y results." The same idea is not terribly hard to implement in Java.
>
> Thanks for any help.
> Tom
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
