On the interaction between JSP and XML

js|xml| Interactive use JavaServer Pages There are three different ways to work with XML documents, each of which helps to improve the level of separation of page code and XML data, simplifies the complexity of developing web pages, and improves the reusability of component and page code.

JavaServer Pages (JSP) and XML are the two crucial components of Sun's Java EE. JSP is an effective tool for creating application server-side programs, and customers can be a browser, a device, or another application. You can use XML to describe the data and pass it between the contact server and the rest of the system. If you consider the abstract concept of Web services carefully, JSP can be considered as implementing technology while XML is data encapsulation and messaging technology. JSP pages can use XML in three ways: Using XML files directly, using JavaBeans to perform XML processing, or using XML through tag libraries.

  First, using XML directly

We can use XML directly in the JSP page, which is divided into three categories:

1. JSP can read XML files and perform actions based on these data. For example, an application can read an XML file that has some specific structure of data.

2. JSP can create an XML file to send data to a client program or other application. A JSP can transform an XML file, which can be given to XSLT processing, either as a controller by a JSP, or through a non-XSLT solution. In both cases, the function of the JSP is to read the XML file, convert it, and generate an output.

Because the JSP contains embedded Java programs, it can directly invoke an analyzer to read/write XML data. This is a very unreasonable method, because the data and code logic are not very good to be separated away. In addition, such procedures are difficult to read. So, I'll introduce the second method: Using JavaBeans.

  Second. Use of JavaBeans

JSP can be closely integrated with the JavaBeans through <jsp:usebean> tag. The following fragment demonstrates how to use a JavaBean in a JSP page to set and get properties.

<jsp:usebean id= "CB" scope= "session" class= "Xmlrep. Customer "/>
<jsp:setproperty name= "CB" property= "id" value= "/>"
<B> A: </B>
<%=cb.getfname ()%>
<p>
<B> last Name is: .</b>
<%= Cb.getlname ()%>

The feature of JSP and JavaBeans integration is that it can automatically translate the form elements of Hypertext Markup language into JavaBean attributes. If you have an HTML form and you want it to submit the form content to JavaBean, you can write the following code:

<jsp:setproperty name= "CB" property= "*"/>

The Name property contains the value that the JSP page already refers to the bean. Front <jsp:useBean> mark set name is "CB". Unlike setting individual bean properties, you can use the asterisk to flag the "all" property. The JSP page automatically maps an HTML form value to a bean property with the same name. If you read each HTML form element and then call the corresponding property's bean set method, the result will be the same.

As you can see, the markup for class XML allows JSP pages to access JavaBeans. By turning the encapsulated code into a reusable component (JavaBeans) as much as possible, we can optimize the code in the JSP page to the minimum level. You can use a generic parser, like Xerces or JAXPI, to interact with an XML file in a separate JavaBeans-and you can change the parser without changing the JSP page. In addition, beans can use XSLT to perform transformations of XML files.

Using JSP and JavaBeans to do these abstract actions is much better than inserting the original Java program directly into the JSP page, but you still need to familiarize yourself with the Java program so that you can change the JSP page at any time. Application consistency and bar rationality depends on JavaBeans cooperation to create a unified output of the good and bad degree. For example, a flaw in a bean can cause the entire XML output to be invalid. Depending on the method that beans specifies the resource, it can also cause performance problems.

  Third, through the tag library JSP and XML interaction

This is the point mentioned in the previous article, but because it is so important, I have to mention it in this article. Tag libraries can define custom tags that appear in JSP pages as class XML elements, associating specific Java code with each tag. For example, suppose you have access to a weather database, and you need to export the current weather conditions. Then, you can insert the JDBC code into the JSP to query the database directly (although this is not a good choice), encapsulate the code in a JavaBean, or wrap it into a tag library. With the last option, the program code in your JSP page looks like this:

<% @taglib uri= "The TLD file" prefix= "foo"%>
Current weather is <foo:Weather/>

Notice that no traces of Java code are visible in the above program code. As a page designer, you use a familiar syntax like <FOO:WEATHER/>, which looks very similar to any of its tags. Insert it in the page where the HTML string containing the current weather condition is inserted.

The tag library has an associated XML-formatted descriptor file named Tag Library descriptor (Tag libraries descriptor, TLD). Each tag in a TLD file has an entry, including its name, version, and other optional information. In the JSP page, you can specify the TLD file with the "<%@_taglib prefix =" foo "%>" instruction. The property "prefix" is used to specify a prefix used to refer to any tag within a JSP page using a particular Coulai. So why do we use tags <foo:Weather/> not just <Weather/>. The exact location of the TLD file depends on the application server that is being used.

A tag library tag can replace the corresponding Java program code to complete this program logic. Each tag is equivalent to a Java class of the same name. This class must implement the TagSupport interface, which contains the capture event trigger method as the JSP engine that handles this page. The first time it encounters this tag, the engine calls the doStartTag () method. You can make this method empty or execute the application logic when it is needed. When the method returns Skip_body, the engine skips the tag body. When it returns to Eval_body_include, the engine processes the tag and its child tags. Similarly, the JSP engine calls the Doendtag () method after parsing the closing tag. The Doafterbody () method allows you to perform actions after the engine processes the element body, but must precede the Doendtag () method. Here is a sample program code for the weather class that implements the weather conditions:

Import javax.servlet.jsp.*;
Import javax.servlet.jsp.tagext.*;
Import java.io.*;
public class Weather extends TagSupport {
public int doStartTag () {
try {
JspWriter out = Pagecontext.getout ();
Out.print ("Sunny and cloudy mixed with" +
"Rain and Sunshine.");
catch (IOException e) {
System.out.println ("Error" + e);
}
return (Skip_body);
}
}

When the engine encounters a "<somePrefix:Weather/>" tag, it searches for a class with the same name in the tag library. If the doStartTag () method is implemented (as in this case), it will be invoked. This allows the string to contain the weather conditions that are displayed. Because the method returns the Skip_body,jsp reader moved to the end of the tag.

The simplest way to use the JSP and tag libraries is to use the Apache Tomcat engine. This engine also acts as a reference implementation of the servlet and JSP application interfaces.

When you use a tag library, the JSP page looks very much like an XML file. When the JSP page is processed, the engine executes the program code associated with the tag (in effect, the JSP engine is first called to translate the JSP page into a servlet and then the servlet is compiled). The methods associated with the tag library are included in the servlet. , a person familiar with XML can design and experiment with a variety of page layouts without having to change any Java program code. Of course, the degree of separation between code and data is primarily dependent on the quality of the markup library element design.