This article describes the usage of page directives in jsp. Share it for your reference. The details are as follows:
1. JSP directive
JSP directives (directive) affect the overall structure of servlets generated by JSP pages. The following template gives two possible forms of instructions. Double quotes on both sides of the property value can be replaced with single quotes, but quote marks cannot be completely omitted. If you want to use quotes in attribute values, you want to add a backslash before them, 'Use \', "Use \"
<% directive attribute="value" %> <% directive attribute1="value1" attribute2="value2" ...... attribute3="value3" %>
In JSP, there are three main types of directives: page, include and taglib. The page directive allows control of the structure of a servlet through class import, customization of the servlet superclass, setting of content types, and so on. The page directive can be placed anywhere in the document. The second directive, include, allows inserting a file into a JSP page when a JSP file is converted to a servlet. The include directive should be placed where the document wants to insert the file. The third directive, taglib, defines custom tag tags.
2. JSP page directive
The page directive can define the following case-sensitive properties (listed roughly by frequency of use): import, contentType, pageEncoding, session, isELIgnored (JSP 2.0 only), buffer, autoFlush, info, errorPage, isErrorPage, isThreadSafe, language, and extends.
2.1 Import Properties
Use the import property of the page directive to specify the package that the JSP page should enter. In JSP, packages are absolutely required. The reason is that if the package is not used, the system considers the referenced class in the same package as the current class. For example, suppose a JSP page contains the following scriptlet:
Here, if Test is in an input package, there is no ambiguity. However, if the Test is not in the package, or the page does not explicitly import the package to which Test belongs, the system will think that the Test is in the package where the automatically generated servlet is located. But the problem is that the package where the automatically generated servlet is located is unknown! When a server creates a servlet, it often determines its package based on the directory where the JSP page is located. Other servers may use other different methods. Therefore, you cannot expect classes that do not use packages to work properly. The same is true for beans, because beans are just classes that follow some simple naming conventions and structural conventions.
By default, servlets import .*, .*, .*, and perhaps some server-specific packages. When writing JSP code, never rely on any automatically imported server-specific classes. Doing so will make the code non-portable.
When using the import property, you can take the following two forms:
<%@ page import="" %> <%@ page import="package.class1, ..., " %>
For example, the following directive indicates that all classes in packages and packages do not need to give explicit package identifiers when used:
import is the only property in the page that allows multiple occurrences in the same document. Although the page directive can appear anywhere in the document, it is generally either to place the import statement near the top of the document or before the corresponding package is first used.
2.2 contentType and pageEncoding properties
The contentType property sets the Content-Type response header, indicating the MIME type of the document to be sent to the client program. For more information about MIME types, see Java Web Development (5) HTTP Response Header.
When using the contentType property, the following two forms can be taken:
<%@ page contentType="MIME-TYPE" %> <%@ page contentType="MIME-Type; charset=Character-Set" %>
For example, directive
The same function as the scriptlet below
The first difference between the two forms is the use of explicit Java code (which is the way some developers try to avoid), while the page directive uses only JSP syntax. The second difference is that instructions are specially processed, and they do not directly become _jspService codes at the location where they appear. This means that the page directive can be called conditionally, while the page directive cannot. Conditionally setting the type of content is mainly used when the same content can be displayed in many different forms.
Unlike regular servlets (the default MIME type is text/plain), the default MIME type of JSP pages is text/html (the default character set is ISO-8859-1). Therefore, if the JSP page outputs HTML as the Latin character set, you don't need to use contentType at all. If you want to change the type and character set of content at the same time, you can use the following statement:
However, if you just want to change the character set, it is easier to use the pageEncoding property. For example, a Chinese JSP page can use the following statement:
You can consider using JSP to implement an example of generating Excel tables in Java Web Development (5) HTTP response header to understand the role of contentType.
2.3 session attributes
The session attribute controls whether the page participates in an HTTP session. When using this property, the following two forms can be taken:
<%@ page session="true" %> <%--Default--%> <%@ page session="false" %>
The true value (default) means that if there is an existing session, the predefined variable session (type HttpSession) should be bound to an existing session; otherwise, create a new session and bind it to the session. The false value indicates that the session is not created automatically. Access to the variable session will cause an error when the JSP page is converted to a servlet.
For high traffic websites, using session="false" can save a lot of server memory. But be aware that session="false" does not disable session tracking, it simply prevents JSP pages from creating new sessions for users who do not yet have sessions. Since the session is for users, not for chastity, there is no benefit to close session tracking for a certain page unless it is possible that the relevant pages visited in the same customer session will be turned off.
2.4 isELIgnored property
The isELIgnored property controls whether to ignore (true) the JSP 2.0 expression language (EL), or perform normal evaluation (false). This is a new attribute introduced in JSP 2.0; it is illegal to use this attribute on servers that only support JSP 1.2 and earlier versions. The default value of this property depends on the version used by the web application. If you specify servlet 2.3 (corresponding to JSP 1.2) or earlier, the default value is true (but changing the default value is still legal, and this property is allowed in JSP 2.0-compatible servers, regardless of the version). If servlet 2.4 (corresponding to JSP 2.0) or later is specified, the default value is false. When using this property, the following two forms can be taken:
<%@ page isELIgnored="false" %> <%@ page isELIgnored="true" %>
2.5 buffer and autoFlush properties
The buffer property specifies the size of the buffer used by the out variable (type JspWriter). When using this property, the following two forms can be taken:
<%@ page buffer="sizekb" %> <%@ page buffer="none" %>
The server may actually use a buffer larger than specified, but not smaller than the specified size. For example, <%@ page buffer="32kb" %> means that the content of the document should be cached and the document should not be sent to the customer unless the accumulation is at least 32KB, the page is completed, or the output is explicitly cleared (for example using response. flushBuffer).
The default buffer size is server-related, but at least 8KB. If you want to turn off the buffering function, you should be very careful: Doing so requires that the JSP elements that set the header or status code appear at the top of the file, before any HTML content. On the other hand, sometimes every line of outputting content takes a longer generation time, and it is more efficient to disable buffering or use small buffers; this way, users can see each line immediately after it is generated, rather than waiting longer to see grouped rows.
The autoFlush property controls whether the output buffer should be automatically cleared (default) after the buffer is full, or an exception should be thrown after the buffer overflows (autoFlush="false"). When using this property, the following two forms can be taken:
<%@ page autoFlush="true" %> <%--Default--%> <%@ page autoFlush="false" %>
When buffer="none", the false value is illegal. If the client program is a regular web browser, then the use of autoFlush="false" is extremely rare. However, if the client is a custom application, you may want to make sure that the application either receives the full message or has no message at all. The false value can also be used to capture database queries that produce too much data, but it is generally better to put this logic in the data access code (rather than representing code).
2.6 info attributes
The info attribute defines a string that can be obtained in the servlet through the getServletInfo method. When using the info attribute, it takes the following form:
2.7 errorPage and isErrorPage properties
The errorPage property is used to specify a JSP page that handles any exceptions thrown but not caught in the current page (i.e. an object of type Throwable). It is applied as follows:
The specified error page can access the thrown exception through the exception variable.
The isErrorPage property indicates whether the current page can be used as an error page for other JSP pages. When using the isErrorPage property, the following two forms can be taken:
<%@ page isErrorPage="true" %> <%@ page isErrorPage="false" %> <%--Default--%>
2.8 isThreadSafe property
The isThreadSafe property controls whether the servlet generated by the JSP page allows parallel access (default) or does not allow multiple requests to access a single servlet instance at the same time (isThreadSafe="false"). When using the isThreadSafe property, the following two forms can be taken:
<%@ page isThreadSafe="true" %> <%--Default--%> <%@page isThreadSafe="false" %>
Unfortunately, the standard mechanism for blocking concurrent access is to implement the SingleThreadModel interface. Although the use of SingleThreadModel and isThreadSafe="false" was recommended in the early days, recent experience has shown that SingleThreadModel is poorly designed, making it basically useless. Therefore, isThreadSafe should be avoided and explicit synchronization measures should be used instead.
2.9 extends attribute
The extends property specifies the superclass of the servlet generated by the JSP page. It takes the following form:
This property is generally reserved for developers or providers, and they make fundamental changes to how the page works (such as adding personalized features). This property should be avoided by the general person unless a class is referenced by the server provider specifically for this purpose.
2.10 language attributes
From a certain perspective, the function of the language attribute is to specify the scripting language used by the page, as shown below:
As of now, since Java is both the default choice and the only legal choice, there is no need to care about this attribute anymore.
I hope this article will be helpful to everyone's JSP programming.