I think there is a problem with JSP (I)

(Editor: when the original article appeared abroad for the first time, JSP was just a new technology and was not as popular as it is now. It seems that some of the ideas in this article may have some limitations, but I have to admit that this is a very atmospheric work, which involves many internal principles of JSP. Therefore, I think it is necessary to introduce this article to you so that you can learn more about JSP technology from the other side .)

Today, every developer who uses servlets knows JSP, a web technology that is built on servlet technology invented by Sun and has spent a lot of energy to implement. 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. "

This article compares JSP with another technology based on servlets: template engines (template engine ).

Problems with using Servlets directly
When Servlets was invented, 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 backend databases, therefore, 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, which is a heavy and time-consuming task for 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 was born
JSP 0.90 was born. 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 views ). They are a component used to display client request results. 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, 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
If the template engine is used to replace the common JSP, the subsequent design will become 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 built such engines, probably WebMacro, whose engines are free of charge.

Developers should understand that choosing a template engine to replace JSP provides the following technical advantages, and these are also 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 done in Java, that is, the simplified modification of c ++. template engines also simplifies it by moving the lower-layer source code in jsp. Template engines implements a better design.

Question #2: Writing Java code is required

Some Java code is required on the JSP page. For example, if 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 the following unreadable strings:

<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 = "$ Request. ContextPath;/index.html"> Home page </a>

In WebMacro, ContextPath serves as an attribute of the $ Request variable and uses Perl-like syntax. Other template engines use other syntax types.

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 $ Cookie. colorscheme = "blue"

In the last example, we assume that we need to reset the color settings in the original cookie. 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"); %>

There is no need for tool classes in WebMacro, usually:

$ Cookie. colorscheme. Value

Which syntax is easier to learn for graphic interface designers who must write jsp?

JSP 1.1 introduces a custom tag (custom tags) that allows any HTML-Like tag to execute Java code in the background on the JSP page. This 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.