Some problems and solutions that plague JSP (1)

Every developer who uses servlets now knows that JSP is a web technology invented by Sun and put a lot of effort into implementation and constructed on top of servlet technology. JSP disconnects the html code in the servlet, which can accelerate web application development and page maintenance. In fact, the official "Application Development Model" document published by Sun goes further: "JSP technology should be regarded as a standard, while servlets can be seen as a supplement in most cases. "(Section 1.9, views ).

The purpose of this article is to listen to the evaluation of the rationality of this statement-by comparing JSP and another technology based on servlets: template engines template engine ).

Problems with using Servlets directly

At first, servlets was invented, and the whole world saw its superiority. Servlet-based dynamic web pages can be quickly executed, and can be easily transferred between multiple servers, and can be perfectly integrated with the background database. Servlets is widely accepted as a preferred web server platform.
However, the html code that can be implemented simply requires the programmer to call each line of HTML through out. println (), which becomes a serious problem in the actual servlet application. HTML content has to be implemented through code. It is a heavy and time-consuming task to ignore large HTML pages. In addition, the person in charge of webpage content has to ask the developer for all updates. To this end, people seek a better solution.

JSP!

JSP 0.90 appears. In this technology, you can embed Java code into HTML files, and the server will automatically create a servlet for the page. JSP is considered a simple way to write servlet. All HTML can be directly obtained without calling out. println (). The person in charge of page content can directly modify HTML without the risk of cracking Java code.

However, it is not ideal for webpage art designers and developers to work on the same file. It turns out that embedding Java in HTML is just as embarrassing as embedding HTML in Java. Reading a bunch of messy code is still a difficult task.

As a result, the use of jsp has become more mature, and more use of JavaBeans. Beans contain the business authorization code required by jsp. Most code in JSP can be extracted and put into bean, leaving only a few labels for calling bean.

Recently, people began to think that JSP pages in this way really look like view ). They are a component used to display the results of client requests. As a result, people may wonder, why not directly send requests to the view? What if the target view is not suitable for this request? In the end, many requests have multiple possibilities to obtain the view of results. For example, the same request may generate a successful page, a database Exception error report, or an error report without parameters. The same request may generate an English or Spanish page, depending on the locale of the client. Why must the client directly send the request to view? Why shouldn't the client send requests to some common server components and let the server decide the return of JSP view?

This allows many people to accept the design known as "Model 2", which is a model defined in JSP 0.92 Based on Model-view-controller. In this design, the request is sent to a servlet controller, which executes a commercial token and generates a similar data "model" for display. This data is then displayed by sending it to a JSP "view" internally, which looks like a common embedded JavaBean. You can select an appropriate JSP page for Display Based on the internal logic of the servlet to be controlled. In this way, the JSP file becomes a beautiful template view. This is another kind of development that has been promoted by other developers so far.

Enter Template Engines

The template engine is used to replace the common JSP. The subsequent design will be simpler, the syntax will be simpler, the error information will be easier to read, and the tools will be more customized. Some companies have already done such an engine, and the most famous is probably WebMacro (http://webmacro.org, from Semiotek) whose engine is free of charge.

Developers should understand that choosing a template engine to replace JSP provides such technical advantages, which is also some of the shortcomings of jsp:

Question #1: Java code is too templated

Although it is considered a poor design, JSP still tries to add Java code to the web page. Some of these seem to have been done in Java, that is, the simplified modification to C ++. template engines also simplifies it by moving the lower-layer source code in jsp. Template engines implements a better design.

Question #2: Java code is required

Some Java code is required on the JSP page. For example, assume that a page needs to determine the root context of the current web application and direct it to its homepage,

The following Java code is recommended in JSP:

＜a href="＜%= request.getContextPath() %＞/index.html"＞Home page＜/a＞

You can try to avoid Java code and use the <jsp: getProperty> flag, but this will give you six strings that are hard to read:

＜a href="＜jsp:getProperty name="request" property="contextPath"/＞/index.html"＞HomePage＜/a＞

Using template engine, there is no Java code or ugly syntax. Here is the same requirement in WebMacro:

＜a href=".ContextPath;/index.html"＞Home page＜/a＞

In WebMacro, ContextPath uses other syntax types as template engines.
Let's look at another example. Assume that an advanced "view" requires a cookie to record the default color configuration of the user. This task may only be completed by the view rather than the servlet controller. The following Java code should be available in JSP:

＜% Cookie c = new Cookie("colorscheme", "blue"); response.addCookie(c); %＞

In WebMacro, there is no Java code:

#set .colorscheme = "blue"

As the last ion, if you want to retrieve the color settings in the original cookie again. For JSP, we can think that there is also a corresponding tool class to help, because using getCookies () directly to do this lower layer will become ridiculous and difficult. In JSP:

＜% String colorscheme = ServletUtils.getCookie(request, "colorscheme"); %＞

In WebMacro, there is no need for tool classes. It is usually:. colorscheme. Value. Which syntax is easier to learn for the graphics artist who writes jsp?

JSP 1.1 introduces the custom tag custom tags) allows arbitrary HTML-like tags to execute Java code in the background on the JSP page, which will be of some value, but the premise is to have a widely known, full-featured, free, standardized tag library. There is no such tag library.

Question #3: simple work is still tiring

Even a very simple job, such as header and footer, is still very difficult in JSP. Assume that a "header" and a "footer" template are included on all pages, and each template must contain the current page title in the content.

In JSP, the best solution is:

<% String title = "The Page Title"; %> <% @ include file = "/header. jsp "%>... your page content... <% @ include file = "/footer. jsp "%>

The page designer should remember not to omit the semicolon of the first line and define the title as a string. In addition,/header. jsp and/footer. jsp must be in the root directory and must be a complete file that can be accessed.
It is relatively simple to include headers and footers in WebMacro:

# Set 24 = "The Page Title"
# Parse "header. wm"
Your content here
# Parse "footer. wm"

There is no semicolon or title definition to remember for the designer. The. wm file can be placed in a customizable search path.