JSP Tag Library

Introduction: JavaServer Pages (JSP) technology is an excellent architecture for developing WEB applications, but one of its most important practical technologies-the custom tag library-is often underutilized. The main reason why tag Library practical technology is not fully utilized is not technical, but language. Tag library producers and consumers are not speaking the same language. JSP experts and consultants Noel J. Bergman reveals the nature of the problem and provides a number of possible solutions.

Separating the underlying content model from the presentation is a good thing, which is universally acknowledged among WEB application developers. In most large development projects, programmers are responsible for implementing the backend, and the representation is left to one or more Web page designers. This division of labour ensures that the final product is technically reliable and well represented, but it certainly requires effective communication and cooperation from two teams. This can be a challenge, given the different knowledge base on which each group works, and the very different concerns.

Before introducing a custom tag library in version 1.1 of the JavaServer pages (JSP) specification, you must use the JSP scripting element to provide arbitrary customization functionality within the JSP page. Using scripting elements explicitly violates the principle of separating the model from the presentation. Using scripting elements explicitly also requires that Web page designers have Java programming experience if they want to do anything other than "Retrieve attributes from the JavaBean component." This raises widespread concern about the use of scripting elements in JSP pages, which then leads to the development of alternative solutions.

A classic solution is to develop model-view-Controller (Model-view-controller)-type usage models. In this use model, the smart part of the application is placed in the servlet and Bean, and the JSP page is only responsible for retrieving the content and rendering it. Jakarta Struts is a good example of this model. Other development teams have created alternative technologies such as the Velocity content engine or Apache cocoon engineering.

Although these solutions have their own advantages, they are often non-standard and overlook the continued development of JSP technology. In this article we will focus on one of the least-used practical techniques in JSP technology: Custom tag Libraries. My goal is to change the way you think about the custom tag library (more specifically, the markup design). My discussion starts with some misunderstandings about JSP technology and some of its alternative solutions, and then moves on to the central topic.

JSP technology: Misunderstanding and alternative solutions

There are many common misconceptions about JSP technology, some of which are often outdated and scare off potential users. Table 1 lists some of the most common misconceptions.

Table 1. JSP: Misunderstanding

" The/tr>

misunderstanding	Truth
jsp page requires that the code model and presentation be blended in the form of script elements.	as we'll discuss in the next section, the tag library proves that this is a false statement.
jsp page scripting is actually Java programming.	> This is only partially true. Since version 1.0, the JSP specification has been allowed to use a variety of scripting languages. However, this function has not been widely implemented. IBM WebSphere allows for a variety of scripting languages, and its underlying technology is published in open source (see the "Workaround for workaround" for the next note). In addition, the Velocity template language (velocity template language) is also available through the JSP tag library.
jsp page is not good because it allows scripting. The complaint of the

Each of the misconceptions listed above has been at least partially correct. However, JSP technology is the main part of Java EE specification and has been widely used. Therefore, there will be many manufacturers through a variety of efforts to develop JSP technology and make it mature to address the concerns of users. This is one of the benefits of using standard technology instead of using a specialized solution.

Nonetheless, there is a common mindset among the managers who are responsible for deploying WEB applications. Not knowing the truth behind the misunderstanding, and being told that JSP technology mixes programming and presentation, the managers ' first reaction is that they will seek alternative JSP solutions, such as Velocity. So the question is, can a solution like Velocity really solve the problem?

The velocity document says it "allows anyone to use this simple but powerful template language to refer to objects defined in Java code", and the document also says that the Velocity template language (VTL) is designed to provide the easiest, easiest, and cleanest way to combine dynamic content into the Web Page. Even a Web page designer with little or no programming experience should soon be able to use VTL to integrate dynamic content into a Web site. "In other words, Velocity does not remove programming from the presentation; it asks the user to learn a new, specialized scripting language." Because velocity requires the Web page designer to learn the Velocity template language, it fails to eliminate the "content and presentation blending" problem.

Velocity is just one example of many template engines on the market, but most template engines, such as velocity, require certain front-end programming skills.

Another popular alternative solution for JSP technology is cocoon engineering. Cocoon is a likable technique that uses XML as its source data format. The role of the XSLT transformation is to convert the XML content into a format appropriate for the user agent, for example, for browser-appropriate HTML. Cocoon has its own dynamic page format called XSP. XSP is a relative of the JSP, but it works in a cocoon environment. The reason XSL is widespread is that there is no good way to send XML output from a JSP page through cocoon to the browser. The servlet link mechanism in the early servlet container is not up to this task. Now, however, Sun has introduced a new servlet filter mechanism that is fully capable of sending XML output from any servlet through a series of filters. From this perspective, the need for XSP is significantly reduced, and the need for Cocoon engineering to provide its XSLT transformation engine as a servlet filter becomes clear as well.

Crucially, JSP technology is evolving to meet the needs of its users. This means that any assessment of JSP technology must take into account the prudent review of its latest specifications. Even a few months ago, the comments and editorials would be obsolete by new developments (see Resources).