You will also need a Hibernate configuration file. Create a shop database in Derby. Username and password are root and pass respectively. If it does not work out - do not be discouraged - I will devote more time to this.

org.hibernate.dialect.DerbyDialect org.apache.derby.jdbc.ClientDriver jdbc: derby: // localhost: 1527 / shop root pass UTF-8 update

We will talk about how to fill in our databases later. You can fill them in manually. Or wait for the next lesson.

Introduction

Java Server Pages (JSP) technology is part of the unified technology for building J2EE business applications. JSP is an alternative technique for developing applications that dynamically generate responses to specific client requests. Before the JSP document is used, a special procedure converts it to the appropriate servlet. In turn, a servlet is usually written in Java language and implements a specific interface. Further, the servlet is also not a standalone application and functions only when placed in the appropriate web container. The web container provides data exchange between the servlet and clients, takes care of such functions as creating a software environment for a functioning servlet, identifying and authorizing clients, organizing a session for each of them.

On the currently the JSP page is translated into a servlet, the program code of which is written in the Java language. However, the authors of the Java Server Pages specification leave it possible to implement JSPs in other programming languages.

The relationship between servlets in a line-of-business application and URLs on the server is specified in the deployment descriptor. Servlet implementation technology is discussed in a separate article. For now, it is important to note that the code used to write servlets is not always convenient for dynamically generating text documents in response to a client request. For example, a snippet of a servlet that generates a dynamic HTML pages might look like this:

PrintWriter out = res.getWriter (); out.println (" "); out.println (" "); ... out.println (""); out.println (""); out.close ();

As you can see, each HTML string document in the servlet corresponds to a certain piece of program code, which does not contribute to the ease of development and maintenance of business applications.

It is more convenient to separate the dynamic and static parts of the generated web page. You will continue to use Java or another programming language to create the dynamic part. It makes sense to design the static part as a text document - Java Server Page (JSP page), designed in accordance with HTML requirements, XML, or another markup standard. In fact, a JSP page can be thought of as a template or prototype of a dynamic page, which remains to be supplemented with dynamic elements. To describe the dynamic component, the JSP technology provides two main mechanisms: JavaBeans and libraries of additional tags. As a result, the JSP technology presupposes the parallel work on the application by two different specialists: a programmer and a person responsible for layout of documents (web masters), who are responsible, respectively, for the development of dynamic and static parts of documents generated in response to customer requests.

As mentioned, before you can use a JSP page, you need to transform it into an appropriate servlet. This transformation can be performed either when the JSP page is placed on the server, or when the client first accesses the page. Since the conversion procedure is quite laborious and time-consuming, it is usually performed only once. However, the server will automatically redirect subsequent calls from the client to the JSP page to the servlet that was received as a result of its transformation.

The servlet obtained after transforming the JSP of the page operates within a standard servlet container and uses a highly regulated interface. Therefore, this technology does not depend on any features of a particular hardware platform. On the other hand, since JSP technologies can be built on the basis of the Java interpreted language, this gives a guarantee of portability of applications built on JSP technology to any platform where you can install virtual Java car.

JSP page

Typically a JSP page is stored in separate file with the extension .jsp. Most of the page's JSP content is servlet mapped into a set of out.println () statements. Sample JSP page:

<%@ taglib uri="/exttags.tld" prefix="dscat" %> <%@ page import = "xbcat.util.*" %> All Customers <% Vector menu=pagescroll.getMenu(); if(pagescroll.page.size() > 0) { %>

The dynamic component of the JSP page is represented by three types special elements: directives, actions and scripts. Each of them is discussed in more detail in the corresponding section.

Directives

Since the web container, before using the JSP page provided by the developers of the business application, translates it into the appropriate servlet, it makes sense to provide the ability to leave directives on the JSP page that will control the translation process. Directives have the syntax

<%@ директива... %>

Let's look at some of these directives

The page directive. Declares a number of JSP page properties. Directive syntax:

<%@ page список_параметров %>

Let's describe some of the most interesting parameters of this directive:

• import - As already mentioned, the JSP page must be converted into the program code - the class corresponding to the servlet before use. In turn, the servlet class can refer to other classes from the standard Java libraries or classes from other packages. By default, the servlet class obtained after the JSP page is translated can be associated with the java.lang, java.servlet, java.servlet.jsp, and java.servlet.http packages. If the servlet class needs to communicate with other packages, for example, with xbcat.util as in the above JSP page example, the latter should be supplemented with a page directive that has an import attribute with the name of the corresponding package.
• session - If the HTTP protocol is used to communicate with a client, a session object is created by default for each session, which allows storing information about this client in the interval between its calls to the server. On the other hand, if the session attribute was specified with the value false, this allows you to refuse to create a session object and use the freed server resources for other tasks.
• buffer - The content of the page created in response to the client's request is passed by the servlet to the out output stream, from where it is then passed by the web container directly to the client. In order to obtain a more optimal transmission mode, this stream is provided with a buffering mode. The default buffer size is 8 kilobytes. The buffer parameter of the page directive allows you to either set a different buffer size, or to abandon the buffering mode altogether by passing the value "none" to the attribute.
• isThreadSafe - According to the servlet specification, the default web container allows the same servlet instance to process requests from multiple clients in parallel. In this case, a separate thread is allocated to each of the requests. However, in some cases it can be useful to disable parallel query processing. (The corresponding controller in the web container queues incoming requests and passes them to the servlet for processing strictly one at a time.) To do this, it is enough to use the isThreadSafe attribute, with the value false.
• pageEncoding - Allows the application developer to declare the encoding to be used in the document passed to the client. By default, the page is considered to be in ISO-8859-1 encoding.
• contentType - In response to a client request, the default JSP page generates a document HTML type... At the same time, the field of application of Java Server Pages technology is much wider, since it allows you to generate any other types of text documents: XML, WML, VRML, etc. The MIME type of the generated document is declared with the contentType attribute. As already understood, this attribute is set to "test / html" by default. Together with the document type, the JSP specification allows the encoding of the generated document to be specified in the same attribute.

The taglib directive. Allows you to use additional tags created by the application developer (custom tags) on JSP pages. Directive syntax:

<%@ taglib uri="URI библиотеки тэгов" prefix="имя префикса" %>

where, uri is an absolute or relative URI that uniquely identifies a handle to the tag library associated with the specified prefix. The specified prefix is ​​used to identify matching custom tags.

<%@ taglib uri="http://www.mycorp/supertags" prefix="super" %> ... ... ...

We will look at the procedure for creating custom tags later.

Include directive. Used to put texts and program code from other sources into a JSP page. Substitution is performed when the JSP page is translated into the appropriate servlet. An example of using the directive:

<%@ include file="menu.jsp" %>

Note that substitution of materials from an external source can also be performed using a special tag , which will be discussed by us later. The difference between this tag and the described directive is that the substitution is carried out directly in the process of processing a client request, and therefore can be tied to the request parameters.

A fragment of the program code on the JSP page (script)

The script, like other elements, adds a dynamic component to the final document. However, unlike them, a script is a program code placed directly in the JSP text of a page. The script can perform calculations or manipulate objects, which allows you to visually associate the characteristics of the generated page with the parameters of the client's request and the business rules of the application. Script elements are of three types: declarations, scriptlets, and expressions.

Declarations

After the JSP of the page is converted to a servlet, most of its content goes into the _jspService () method, which is called whenever a customer order needs to be processed. A JSP page declaration is most often used to declare additional attributes and methods in a servlet class that will be available when processing any client request. Declarations have the syntax<%! … %> .

Examples of declarations on the JSP page:

<%! int i; %> <%! int i = 0; %> <%! public String f(int i) { ... } %>

Scripts

A scriptlet can contain program code and local variable declarations that will be used to process client requests. In fact, a scriptlet is a piece of program code from a future servlet, which in due time will be placed in the _jspService () method. As a part of the servlet, the scriptlet gains access to the response object and, accordingly, can independently form a certain part of the final dynamic page. However, most often scriptlets are used not for this, but in order to manage objects of business logic and application logic.

The scriptlet has the syntax<% … %>... An example of using scriptlets in JSP page content:

<% if (i == 0) { %>Good morning<% } else { %>Good afternoon<% } %>

To appreciate the clarity and simplicity of this construction, compare it with the equivalent code snippet in a servlet:

if (i == 0) (out.println ("Good morning");) else (out.println ("Good afternoon");)

Expressions

Often, the page transmitted to the client contains the results of calculations or calls to certain methods and attributes of certain classes. Any of these dynamic elements can be converted to a string and presented on a JSP page by calling out.println in the appropriate script:

<% UserProfile user = (UserProfile) session.getValue("Profile"); %> <% out.println(user.getFaxNumber()); %>

The second line in the given example is more convenient and clearer to represent in a more multiple form, using the expression syntax<%= … %> :

<%= user.getFaxNumber() %>

Another example of using an expression in the body of a JSP page:

<%! int i = 0; %>Hi, now the servlet processing<%= ++i %>th request.

JSP pages and objects

In the course of processing requests, the JSP page can access the objects located on the server, create them and modify them. Objects are accessed through script and action elements. Each object created in the application has a certain lifetime, which is declared in the corresponding attribute. The specification provides four intervals:

• page - The object, whose lifetime is defined as page, is accessible only within the JSP page where it was created. All references to this object must be released immediately after the client's request has been processed.
• request - An object whose lifetime is specified as request and is available to all pages associated with processing this request. In particular, if processing is redirected to a new JSP page, this object will be available on both the old and the new page. As in the previous case, references to the object must be released after the request has been processed.
• session - A session-scoped object is available to all pages handling requests associated with a specific session (a session with a specific client). References to objects associated with the session are placed in the session object. At the end of the session, the links must be released.
• application - Most general scope. Objects scoped with application are not tied to any separate page or session and are accessible from all JSP pages of this application.

JSP page always has access to a specific set of objects, created by the web the default container:

• request - An object containing the client's request. Refers to the javax.servlet.ServletRequest class, or another class that inherits from it. For example, for the HTTP protocol, this would be an object of the javax.servlet.http.HttpServletRequest class. The scope of the object is request.
• response - The object into which the servlet will place the response to the user's request. Refers to the javax.servlet.ServletResponse class, or another class that inherits from it. For example, for the HTTP protocol, this would be an object of the javax.servlet.http.HttpServletResponse class. The scope of the object is request.
• pageContext - An object that defines the JSP context of the page. Object scope - page
• session - An object created by the container to identify the client, as well as store personal objects. Created by the container for the HTTP protocol and is an instance of the javax.servlet.http.HttpSession class.
• application - An object associated with the configuration of the servlet corresponding to this JSP page. The object's scope is application.
• out - An object containing the servlet's output stream. The information sent to this stream will be sent to the client. The object is an instance of the javax.servlet.jsp.JspWriter class. For example, most of the static template on a JSP page should ideally be written in the form of an appropriate set of out.println () commands. The object's scope is page.
• config - Object associated with servlet configuration. Instance of the javax.servlet.ServletConfig class. For a JSP page, the scope of the config object is page.
• page - The object associated with rendering this page. Scope - page

Action elements

Regardless of the type of document generated in response to a user request, in general, a JSP page contains text and tags. Obviously, the latter correspond to the type of the generated document: HTML, XML, etc. In addition, the body of a JSP page can contain fragments of Java code that must be part of the servlet received after translation: declarations, scriptlets, and expressions. The idea is to supplement the set of standard markup tags with special tags - action elements, behind which the developer of a business application can hide part of the program code related to the application, or some additional instructions.

Note that from the point of view of a layout specialist, action elements are the same tags as all the others, and therefore they are permissible. sharing with other elements:

Let's take a look at some of these elements.

Standard action elements

Standard action elements look like regular tags, the name of which begins with the jsp: character combination, for example ... In XML terminology, this means that the standard action elements in JSP technology belong to the jsp namespace.

jsp: useBean

The jsp: useBean element allows you to use objects in the JSP page that correspond to JavaBeans. Element contains a parameter that associates a unique identifier with the component. The latter will then be used when referring to this object:

This example creates an object of the com.myco class. In the future, to refer to it, it is enough to use the "customer" identifier. For instance:

<%= customer.getName() %>

By default, objects associated with a JavaBean are scoped to page by default. The developer of the JSP page can specify more long time the existence of a JavaBean by using the scope element when writing the jsp: useBean element. The possible values ​​for this attribute — page, request, session, and application — we discussed earlier when we talked about the scope of objects associated with a JSP page.

We will not cover the rest of the attributes of the jsp: useBean element. Here is just one more example of its use:

The internals of JavaBeans will be discussed in a separate article.

jsp: setProperty and jsp: getProperty

Any class must give access to some of its attributes and methods. The difference between the JavaBean element is that access to its attributes is unified and is implemented on the JSP page using the jsp: setProperty and jsp: getProperty elements.

The jsp: getProperty element takes a Bean instance, retrieves the value of the specified attribute, converts it to a string if necessary, and puts it in the data stream passed to the client. For example, according to the following entry

the generated document is filled with the value of the name property from the Bean instance with the identifier user.

The jsp: setProperty element, unlike the previous one, does not retrieve, but sets a new value for the attribute. For instance:

In addition to explicitly setting new values, the jsp: setProperty element allows you to set an object attribute with a value retrieved from a client request. For instance:

This record means that among the data received from the client is the login parameter and its value is passed to be placed in the name attribute of the Bean object with the identifier "user".

Finally, when the field names in the client request match the attribute names of the Bean, there is another option where all values ​​are migrated at once. For instance:

jsp: include

Like the include directive, this element allows you to put static and dynamic material from an external source into the body of a dynamically generated page. At the same time, although the material borrowed in this way is processed in the same context as current page, it is only given access to the output stream of the servlet. For example, code included in a JSP page should not access cookies or use its own headers that declare the encoding or document type.

The difference between the include directive and the jsp: include element is that the included material for it cannot be dynamic, and the search and processing of possible dynamic fragments is carried out not separately, but after inclusion, with the entire page.

An example of using the jsp: include element:

jsp: forward

This element allows you to redirect the further generation of a dynamic page to another JSP page, servlet, or use a prepared text for completion. For instance:

In the next, more complex example dynamic page ends with content text file whose name is taken from the someValue variable:

In conclusion, it should be noted that there are two main schemes for processing client requests:

In the first case, the processing of the client's request and the formation of a dynamic page in response are performed within a single JSP page or servlet. The latter, if necessary, can access JavaBeans or import material from external sources using the include directive or the jsp: include element.

In the second case, processing is carried out in two stages. First, control is passed to a servlet or JPS page that actually handles the request. For example, data is retrieved from a client request and placed into a database or attributes of certain objects. Control is then passed to a separate JSP page or servlet responsible for generating the dynamic page for subsequent transfer to the client. However, there does not have to be any relationship between processing a request and generating a new page. For example, it may just be a customer return to home page upon completion of any procedure.

Additional tag sets

Introduction

Textual markup protocols such as HTML have a highly regulated set of tags. At the same time, during the development of documents, there is often a need to use additional, special tags, which, although they were not declared in the corresponding specifications, but to a greater extent correspond to the subject area of ​​a business application. On the one hand, such additional or custom tags can be viewed as a kind of macros that will be replaced by an equivalent combination of standard tags before the document is sent to the client. Alternatively, a specific piece of code can be behind the custom tag. For example, a fairly common single tag might be a hit counter or a menu whose content depends on the role a given customer plays in a business process.

Building custom tags involves writing specific program code. JSP technology provides for placing this code in a separate program module - the custom tags library. Development of such libraries can be outsourced to companies. The JSP page is connected to a particular custom tag library using the previously described taglib directive. The specified directive binds the descriptor of the corresponding library with a specific prefix, which, in turn, identifies all custom tags from this library in the body of the JSP page. So, the directive

<%@ taglib uri="/exttags.tld" prefix="dscat" %>

declares that the JSP page uses a library of additional tags, each of which starts with the dscat prefix. For instance:

All Customers

The program code of this library is described by the exttags.tld descriptor. We will not dwell here on the rules for writing a library descriptor, but consider only one of the possible examples of its implementation:

1.0 1.2 dscat pageheader ru.view.tag.PageHeader

Creating a custom tag library

Custom tags without content processing

The code for supporting a custom tag is in a special way a written instance of a Java class that is invoked by the web container whenever it needs to render a JSP page containing the corresponding tag.

In the simplest case, to support a custom tag, you can take any of the business application classes and supplement it with methods that correspond to the Tag interface. If you do not need to use external objects, then TagSupport can be used as the base class. These and other standard classes and interfaces are found in the javax.servlet.jsp.tagext package.

An example of a class supporting a custom tag:

public CopyrightTag extends TagSupport (public int doStartTag () throws Exception (pageContext.getOut (). print (" © Copyright 2001"); return SKIP_BODY;) public int doEndTag () (return EVAL_PAGE;))

Methods of the class that processes the custom tag are called in a specific sequence. When processing reaches the opening custom tag in the JSP page, the doStartTag () method is called to process it. When processing reaches the corresponding end tag, the doEndTag () method is called. The doInitBody () and doAfterBody () methods are used to process the part of the JSP page that is enclosed between these two tags.

In addition to the fact that the doStartTag () method can do any kind of processing on the request, the value it returns is important. If it is SKIP_BODY, then the information enclosed between the corresponding opening and closing tags will be ignored, and the JSP processing of the page will immediately jump to the closing tag. For the content of the custom tag to still be processed, the medot must return EVAL_BODY_INCLUDE. Likewise, if the doEndTag () method returns SKIP_PAGE, then the rest of the JSP page after the end tag will be ignored. To prevent this from happening, the method must return EVAL_PAGE.

In some cases, it is necessary to show the content of a custom tag not once, but several times. In this case, the class that processes the tag must implement the IterationTag interface, or use the TagSupport class as a parent. To redo displaying the custom tag content one more time, the doStartTag and doAfterBody methods must return EVAL_BODY_AGAIN.

Custom tags with content handling

If access to the content of a custom tag is required, then the corresponding Java class must implement the BodyTag interface or inherit from the BodyTagSupport class. In either case, a class can implement the doInitBody and doAfterBody methods.

The doInitBody method is called immediately after the content of the tag is identified, but before it is processed. Typically this method is used when you need to initialize a class based on the content of a custom tag.

The doAfterBody method is called after the content of the custom tag has been processed. As in the previous section, the doAfterBody method can indicate whether to iterate over the tag content again. If necessary, the method should return EVAL_BODY_BUFFERED. Otherwise, it should return SKIP_BODY.

In addition to the two previous ones, the JSP technology provides for a call to the release method in order to allow the class supporting the custom tag to release the resources allocated to it, as well as perform other necessary actions to return to its original state.

The technology provides two methods directly for accessing the content of a custom tag: getString and getReader.

Attributes in custom tags

In addition to the information between the opening and closing tags, a custom tag can have some attributes that can also affect the order in which the client's request is processed. For each of these attributes in the class that implements the custom tag, the corresponding attribute must be specified, as well as two get method and set. For example, if the custom tag looks like

then the class implementing this custom tag should contain the following code:

Good bad