|
JSP-Java Server Pages Practices
|
| Avoid embedding Java code in your JSP pages. Code in scripting elements can easily lead to hard to find syntax errors and too much code in the pages makes the Web application hard to maintain. |
| There's an important difference between a forward and a redirect. When you forward, the target page is invoked by the JSP container through an internal method call; the new page continues to process the same request and the browser is not aware of the fact that more than one page is involved. A redirect, on the other hand, means that the first page tells the browser to make a new request to the target page. The URL shown in the browser therefore changes to the URL of the new page when you redirect, but stays unchanged when you use forward. A redirect is slower than a forward because the browser has to make a new request. Another difference is that request scope objects are no longer available after a redirect because it results in a new request. If you need to pass data to the page you redirect to, you have to use a query string and pass them as request parameters (or save the data as session or application scope objects). |
| Do not put the database access code directly in the JSP page. Instead, create a bean or a custom action that does all the hard work. For a complex application, you may actually want to use a servlet for all database access and let it forward the request to a JSP page that only deals with rendering the result. This model is often referred to as the Model-View-Controller (MVC) model, or Model 2 (a term used in a prerelease of the JSP specification). |
| Database access is typically very expensive in terms of server resources. You should use a connection pool to share database connections efficiently between all requests. |
| In many cases, the database information rarely changes. For instance, product catalog information may change only when products are added or deleted, or when the prices change. For this type of information you can get the data once and save it as an application scope object that all users can access. In the rare event that the information changes, just replace the application scope object with a new version. |
| If you decide to use a cache, don't use the JDBC ResultSet object itself as the cache object. A ResultSet is tightly linked to a specific connection and therefore conflicts with the connection pooling. Instead, copy the data from the ResultSet into an application specific bean, a Vector of Vector's, or something similar. |
|
A JSP page can include page fragments from other files to form the complete response. You can use this, for instance, to keep header, footer, and navigation bar content in separate files and include them in all other pages. There are two include mechanisms: the include directive and the include action. It's not always obvious which one to use, though. Use the include directive if the file changes rarely. It's the fastest mechanism. If your container doesn't automatically detect changes, you can force the changes to take effect by deleting the main page class file. Use the include action only for content that changes often, and if which page to include cannot be decided until the main page is requested. |