I think JSP has a problem

js| Question (Editor: When the original text of this article first appeared abroad, JSP is just a budding technology, and not as it is now. Now it seems that some of the ideas of this article may have some limitations, but I have to admit that this is a very atmospheric work, which involves many of the intrinsic principles of JSP. Therefore, I think it is necessary to introduce this article to you, so that you from another side of a more in-depth understanding of JSP technology. ）



Today, every developer using Servlets knows JSP, a web technology built on the servlet technology that Sun invented and expended a lot of effort to implement. JSP removes the HTML code from the servlet to speed Web application development and page maintenance. In fact, the official "Application development Model" document published by Sun says further: "JSP technology should be seen as a standard, and servlets in most cases as a complement." "

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

The problem of using servlets directly
When Servlets was invented, the whole world saw its superiority. Servlet-based Dynamic Web pages can be executed quickly, easily transferred between multiple servers, and can be seamlessly integrated with back-end databases, so Servlets is widely accepted as a preferred platform for Web servers.

However, the HTML code that is usually implemented in a simple way now has to let programmers call each row of HTML rows through Out.println (), which becomes a serious problem in the actual servlet application. HTML content has to be implemented through code, which can be a heavy and time-consuming task for large HTML pages. In addition, the person responsible for the content of the Web page has to ask the developer to make all the updates. To this end, people are looking for a better way to solve this problem.

JSP birth
JSP 0.90 was born. In this technique you can embed Java code into an HTML file, and the server will automatically create a servlet for the page. JSP is considered a simple way to write a servlet. All HTML can be directly obtained without having to be invoked by OUT.PRINTLN (), and the person responsible for the page content can modify the HTML directly without risking the risk of damaging the Java code.

However, it is not ideal for page art designers and developers to work on the same file, so Java embedding HTML is proving to be as embarrassing as embedding HTML in Java. Reading a bunch of messy code is still a difficult thing to do.

As a result, people in the use of JSP become mature, more use of JavaBeans. Beans contains the business logos code required by the JSP. Most of the code in the JSP can be taken out and placed in the bean, leaving only a few tokens to invoke the bean.

Recently, people began to think that the JSP page in this way really looks like a view. They become a component that displays the results of client requests. So people would think, why not just send a request to the view? What if the target view is not appropriate for the request? In the final analysis, many requests have multiple possibilities to get the result view view. For example, the same request could result in a successful page, database exception report, or an error report with missing parameters. The same request may produce either an English page or a Spanish page, depending on the locale of the client. Why does the client have to send the request directly to view? Why should the client not send the request to some generic server component and let the server decide to return the JSP view?

This has led many people to accept the design that has been called Model 2, which is a model-view-controller based model defined in JSP 0.92. In this design, the request is sent to a servlet controller that performs commercial logos and produces a similar data "model" for display. This data is then sent internally to a JSP "view" to display so that the JSP page looks like an ordinary embedded JavaBean. You can select the appropriate JSP page to display according to the internal logic of the servlet responsible for control. In this way, the JSP file becomes a beautiful template view. This is another development that has been admired by other developers.

Enter Template engines
If you use template engine instead of the usual purpose JSP, the next design becomes simpler, syntax is simpler, error information is easier to read, and tools are more user-readable. Some companies have done this kind of engine, the most famous may be webmacro, their engine is free.

Developers should be aware that the selection of a template engine to replace JSP provides some of the following technical advantages, which are also the shortcomings of JSP:

Problem #1: Java code is too templated

Although considered a bad design, JSP still tries to add Java code to the Web page. This is some of the things Java has done, that is, the simplified modification of C + +, template engines also by the lower level of the JSP in the source code removed to make it simpler. and template engines implemented a better design.

Problem #2: Write Java code required

Require some Java code to be written in the JSP page. For example, if a page is to determine the context of the root in the current Web application to guide its home page, it is best to use the following Java code in the JSP:

Home Page

You can try to avoid Java code while using tags, but this will give you the following string that is hard to read:

/index.html ">homepage

With template engine, there is no Java code and unsightly syntax. Here is the same request in the Webmacro in the wording:

Home Page

In Webmacro, ContextPath as a property of the $Request variable, using Perl-like syntax. Other syntax types are used by other template engines.

Looking at another example, suppose that an advanced "view" needs to set a cookie to record the user's default color configuration-a task that looks likely to be done only by view rather than by a servlet controller. In the JSP you want to have this Java code:

　　

There is no Java code in Webmacro:

#set $Cookie. ColorScheme = "Blue"

As a last example, if you want to retrieve the color configuration of the original cookie again. For JSP, we can think of a corresponding tool class to help, because it becomes ridiculous and difficult to use getcookies () to do such low-level things directly. In the JSP:

　　

There is no need for a tool class in Webmacro, usually:

$Cookie. Colorscheme.value

What kind of syntax is easier to learn for graphic designers who have to write JSP?

JSP 1.1 introduced the custom tags (custom tags) allows arbitrary and HTML similar tags in the JSP page in the background to execute Java code, which will have a certain value, but the premise is to have a widely known, full-featured, free to get, standardized tag library. No such tag library has been present.
Problem #3: Simple work is still tiring

Even simple work, such as header and footer, is still difficult in JSP. Suppose you have a "header" and a "footer" template to include in all pages, and each template contains the current page title in the content.

The best way to do this in a JSP is to:

　　

　　

... The content of your page ...

　　

The page designer should remember not to omit the semicolon from the first line and to define title as a string. In addition,/header.jsp and/footer.jsp must be in the root directory and must be accessible to the full file.

It is simpler to include headers and footers in Webmacro:

#set $title = "The Page title"

#parse "HEADER.WM"

Your content Here

#parse "FOOTER.WM"

There is no semicolon or definition of title to be remembered for the designer, and the. wm file can be placed under a customizable search path.

Problem #4: Very rough cycle

Looping through a JSP is difficult. Here is a JSP to duplicate the name of each ISP object.

　　

Maybe there will be user-defined tags to do these loops. The same is true for "if". The JSP page may look like a very odd Java code. At the same time, the Webmacro cycle is beautiful:

#foreach $isp in $isps {

The next name is $isp. Name


}

#foreach指令可被自定义的 #foreach-backwards instructions are easily replaced if necessary.

This is likely to change with JSP: (here is a possible tag)

　　

The next name is


　　

The designer will of course choose the former.

Problem #5: Useless error messages

JSP often has some surprising error messages. This is because the page is first converted into a servlet before it is compiled. Good JSP tools can relatively increase the likelihood of finding the wrong location, but even the best tools won't make all the error messages easy to read. Due to the process of transformation, some errors may not be recognized by the tool at all.

For example, suppose a JSP page needs to create a title that is common to all pages. There is nothing wrong with the following code:

　　

However, Tomcat provides the following error message:

Work/%3a8080%2f/jc_0002ejspjc_jsp_1.java:70:statement expected.

static int count = 0;

^

This information holds that the above script is put into the _jspservice () method and the static variable is not allowed into the method. The syntax should be. It is difficult for page designers to read these error messages. Even the best platforms are not doing enough in this area. Even if all Java code is moved out of the page, it does not solve the problem. In addition, what is wrong with the following expression?

　　

Tomcat gives:

Work/8080/_0002ftest_0002ejsptest_jsp_0.java:56:class count not found in

Type declaration.

Count

^

Work/8080/_0002ftest_0002ejsptest_jsp_0.java:59:invalid declaration.

Out.write ("\ r \ n");

^

In other words, it's just a missing tag. Should be.

Because template engine can be generated directly in template files without any dramatic conversion to the code, the appropriate error reporting can be easily given. And so on, when the C language command is taken into the Unix shell command line, you don't want the shell to generate a C program to run the command, but simply require the shell to simply interpret the command and execute it, if there is an error.

Problem #6: Need a compiler

The JSP requires a compiler to be placed in the webserver. This becomes problematic because Sun refuses to give up the Tools.jar library that contains their javac compilers. The Web server can be included in a third party compiler such as IBM's Jikes. But such a compiler does not work smoothly on all platforms (written in C + +) and is not conducive to the establishment of a pure Java Web server. JSP also has a precompiled option that can play a role, but not perfect.

Problem #7: Waste of space

The JSP consumes extra memory and hard disk space. For every 30K JSP file on the server, there must be a corresponding class file larger than 30K to produce. Actually doubles the hard disk space. Considering that the JSP file can easily contain a large data file through <%@ include> at any time, such attention has very realistic meaning. At the same time, the class file data for each JSP must be loaded into the server's memory, which means that the server's memory must always keep the entire JSP document tree. A handful of JVMs have the ability to remove class file data from memory, but programmers often cannot control such a rule to restate it, and it may not be very effective for a large site to be declared again. The template engines saves space because it does not produce a second file. Template engines also provides programmers with full control of the templates in-memory caching.

There are also some problems with using template engine
The problem with template #1: There is no strict definition

There is no strict definition of how template engine should work. However, in contrast to JSP, this is not very important, and JSP is different, template engines to the Web server has no special requirements-any support servlet server can support Template engines (including the API 2.0 servers such as Apache/jserv, they do not fully support JSP! If a healthy competition for the best template engine design can lead to a dazzling innovation, especially with the promotion of open source (which allows ideas to drive and promote each other), today's webmacro will be like Perl, There is no strict definition but the promotion of open source organization is its standard.

Template's Problem #2: no recognition

Template engines is not widely known. JSP has occupied a huge commercial market, and deeply rooted. The use of G template engines can only be an alternative technology that is not understood.

The problem with template #3: not ready to deploy

Template engines has not yet been highly deployed. There is no performance test and comparison between the template engine and the JSP. Theoretically, a fully provisioned template engine implementation should match a provisioned JSP, but, given that the third party has made such a far-reaching push for JSP, the result is that JSP is well provisioned.

Role of JSP
Of course, JSP is bound to have its place. Even though the similarity between JSP and ASP can be seen from the name, there is only one letter difference. So if you want to let people using ASP to Java, very similar JSP environment will play a big role in this, and the ASP to maintain this relationship can play a role should also be introduced by the designer of the JSP to focus on.

One thing to emphasize here, however, is that there is a big difference between working with a new environment and the best way to actually use the environment.

The development of JSP has increasingly shown that it is becoming one of the most important Java technology, it allows people to leave the world of ASP-hence, sun will support this strong business case, Java-related technical supporters will also give greater support.

Unfortunately, however, this is not the best solution for the Java platform. This will make the Java solution seem like there is no Java solution.