JSP Best Practices: Controlling dynamic content with Jsp:include

In the previous article in the new JSP best Practices series, you learned how to use JSP include pseudo-directives to include static content such as headers, footers, and navigation components in a Web page. As with server-side inclusions, JSP include pseudo-directives allow a page to extract content or data from another page. Listing 1 revisits the include pseudo-directives.

Listing 1. JSP include pseudo-directives

<! [cdata[<%@ page language= "java" contenttype= "text/html"%>
What you need
All of the best practices in this series are based on JavaServer Pages technology. To run any of these best practices, you need to install a JSP-compliant Web container on your local machine or test server. You also need to encode the JSP pages using a text editor or IDE.
While it include is well suited to incorporate static content into Web pages, it is not ideal for dynamic content. We found this issue in the previous article when we tried to reload the cache file. Unlike most header and footer files, dynamic content changes frequently and must be updated at all times. We'll start with a brief recap include of the limitations of the pseudo-directive, and then I'll show you how to use jsp:include markup to extend the JSP's containment capabilities.
Cache issues
includeone of the disadvantages of JSP pseudo-directives is that it causes the Web browser to cache all pages. This is meaningful when working with static components such as footers, copyright notices, or a set of static links. These files do not change, so there is no reason for the JSP interpreter to continually poll the data in it. Wherever possible, the cache should be implemented because it improves the performance of the application.
JSP Testing and development
When you build a Web application or Web site, you may need to update the header, footer, and navigation links a lot. It can be a pain to be forced to shut down the browser or clear its cache just to see the changes made to the included files. On the other hand, in order to end the development cycle and have to thoroughly review and modify the hundreds of include pages using pseudo-instructions, it is also a painful thing. My recommendation is to disable the browser cache during testing. In most cases, this will solve the problem completely. There are also a few cases where this does not work, and you can constantly restart the Web container on the browser or server to ensure that the cache is not cached.
Sometimes, however, caching is not worth the candle. If the content is coming from a program that uses dynamic data, such as a Weblog or database-driven JSP file, or even if it contains frequently changing HTML (such as a timestamp), it is necessary to display the most recent version of these files or programs whenever a Web page is loaded. Unfortunately, JSP pseudo- include directives do not have this capability. In the Test and development cycle (see sidebar "JSP Testing and development"), disabling caching in a browser can often solve this problem. However, for applications that are actually used, performance is an important factor in any design decision-making process, disabling caching is not a viable long-term scenario. A better solution is to use jsp:include tags.
Back to top of page
Jsp:include Mark
jsp:includeIt's just a different include pseudo-directive. jsp:includeThe advantage of this is that it always checks for changes in the included files. In a moment we will look at how this new marker works. But first look at the two include individual codes so that you can see the similarities and differences between them.
Listing 2 shows a simple page that uses the original JSP include pseudo-directives.
Listing 2. JSP include pseudo-directives
<! [cdata[<%@ page language= "java" contenttype= "text/html"%>
Listing 3 is the same page, except for the use of jsp:include tags.
Listing 3. Turn into use Jsp:include
<! [cdata[<%@ page language= "java" contenttype= "text/html"%>
You should be aware of the two major differences between the two code types. First, the jsp:include element does not use include the syntax that belongs to the pseudo-directive %@ . In fact, the jsp prefix lets the JSP compiler know that it should look for elements in a standard JSP tag set. Second, the attribute that specifies the file to include is changed from file page . If you want, you can test the result of the new tag yourself. Simply change the contents of the file in the previous article (see Resources) and included.html reload the browser page to see the new content immediately.
Flush Property
You may have noticed the jsp:include properties in the code sample flush . As the name implies, flush indicates whether any existing buffers are emptied before they are read into the containing content. A property is required in JSP 1.1, flush so if you don't use it in your code, you get an error. However, in JSP 1.2, the flush property defaults to False. Since emptying is not an important issue most of the time, my advice is: set to true for JSP 1.1, flush and set to off for JSP 1.2 and later.
Back to top of page
How the Jsp:include works
If you are a bit inquisitive, you may be wondering jsp:include why the behavior of the tag differs from the include pseudo-directive. The truth is very simple: jsp:include It contains the response of the included URI, not the URI itself. This means that the indicated URI is interpreted and therefore contains the generated response . If the page is HTML, then there will be no change in HTML. However, if it is a Perl script, a Java servlet, or a CGI program, the result will be the one interpreted from the program. Although the page is usually HTML, the actual program happens to be the means to achieve it. Also, because the page is interpreted every time it is requested, it never caches the results as if it were using include pseudo-directives. Although this is only a small change, it causes all the differences in the behavior you see.
Back to top of page
A mix-and-match solution
includePseudo-directives have their niche on some websites. For example, if your site contains headers, footers, and navigation files that have little or no variation, if there are changes, then the basic include pseudo-directives are the best option for these components. Because include the pseudo-directive takes the cache, the content is cached only once, and the result is a great improvement to the performance of the site.
However, for many WEB applications or sites today, carpet-style caching does not solve the problem. Although headers and footers may be static, it is not possible for the entire site to be static. For example, extracting navigation links from a database is common, and many JSP-based sites also extract content from dynamic JSP pages on other sites or applications. If you are working with dynamic content, you need jsp:include to take care of that content.
The best solution, of course, is to mix and match the two approaches often, using each of these constructs to the most appropriate place. Listing 4 is an example of a mix-and-match containment solution.
Listing 4. Mix and Match Solutions
<! [cdata[<%@ page language= "java" contenttype= "text/html"%>
The code above shows the sample index page in the previous article. Navigation links and footers are static content and change at most once a year. For these files, I used include pseudo-directives. The contents pane contains the Weblog and "bookshelf" components, which are dynamically generated. These two components need to be updated all the time, so I used jsp:include tags for them. The header.jsp file is a little strange. This component is extracted from another JSP page that is essentially static. However, as you will notice, it extracts the page "banner" from the containing page and then displays it. To process this shared information, we must pass in the parameters to the header file. To process those parameters, you must use the jsp:include elements.
JSP Best Practices: Controlling dynamic content with Jsp:include