JSP practice: Use the JSP include mechanism to improve the appearance (1)

All the best practices in this series are based on the assumerver Pages technology. To run any practice, you need to set JSP-compliant Web containers on the local machine or test server, such as Apache Tomcat. You also need to use a text editor or IDE To write JSP page code. See references to obtain links to the list of Tomcat and JSP-compatible Web containers and ides.

Better appearance

Creating consistent design and layout for Web pages is one of the easiest ways to ensure a professional look. You may have seen enough websites to know that most of the pages in a single site share a uniform page header, end of the page, and a certain type of navigation bar. On well-designed sites, these elements will present the same layout, content, and functionality on each page, and the main panel is usually called the content pane) will change with each view.

Previously, this layout was almost entirely implemented by the framework and framework set. Each segment of static content is placed in a frame, and the main content of the page is placed in the intermediate frame. The trouble with frameworks is that different browsers often display them in different ways to make them look different. Using a framework to link external sites from an internal page is more difficult than you think. Originally, users were allowed to view external content without leaving the site, but the results were often inconsistent. What the user sees is that the entire site is congested into a much smaller frame. Worse, your site will eventually be nested in another site frame. This chaos drives Web designers to find a better solution. Server-side includeserver-side include, SSI) is one type.

Server include

Not long ago, SSI was one of the most popular options for creating shared content. The simple SSI directive allows you to create a page that contains another page, such as a header and a footer file, as shown in Listing 1.

Listing 1. SSI being used

＜![CDATA[＜html＞＜head＞＜title＞Simple SSI test＜/title＞＜/head＞＜body＞This content is statically in the main HTML file.＜br /＞＜!--#include virtual="included.html" --＞＜/body＞＜/html＞]]＞

We will soon use this file for an exercise. Currently, you should save it as a test-ssi.shtml. In most settings, SSI files must end with. shtml, which allows the Web server to know that they are parsed as SSI pseudo commands. Listing 2 shows the contents of a file named included.html.

List 2. Contents

＜![CDATA[This content is in another file, included.html]]＞

When you request a test-ssi.shtml, you will see the contents of this file and the contents of included.html. You can view these files on any Web container that supports SSI, such as Apache Tomcat. For more information, see references.

From the user's perspective, SSI has a major improvement over the framework, because there is no obvious difference between a single file and the files imported from other included files. The disadvantage is that SSI requires a specific server setting, which Java developers often cannot use. In addition, SSI usually requires static content to be included, although dynamic content inclusion is added to later versions.

SSI is a viable solution for websites or Web applications that contain different types of content, but they are not the best choice for Java developers. This is not only because the assumerver Pages technology replaces the full Java Technology of SSI, but also because these two technologies are not easily combined. JSP page with extension. end of jsp, which indicates that to enable the SSI pseudo command to take effect, you must change the SSI configuration to parse the JSP file to add overhead for parsing each JSP page), or change the JSP configuration. it is a bad idea to process the shtml extension as a JSP page ). For Java developers, JSP technology is the best content management solution. Fortunately, its include mechanism is easy to master.