Now every developer using servlets knows JSP, a web technology invented by Sun and devotes a lot of effort to promote and build on servlet technology. JSP removes the html code in the servlet, which can accelerate web application development and page maintenance. In fact, the official "Application Development Model" document released by Sun goes further: "JSP technology should be regarded as a standard, and servlets can be regarded as a supplement in most cases." (Section 1.9, 1999/12/15 Listen to Opinions Edition).
The purpose of this article is to hear an evaluation of the rationality of this statement -- by comparing JSP with another servlets-based technology: template engines.
Issues of using Servlets directly
At first, servlets were invented and the whole world saw its superiority. Dynamic web pages based on servlets can be executed quickly, can be easily transferred between multiple servers, and can be perfectly integrated with the backend database. Servlets are widely accepted as the preferred platform for web servers.
However, the html code that is usually implemented in a simple way now requires programmers to call each HTML line through (), which has become a serious problem in actual servlet applications. HTML content has to be implemented through code, which is a time-consuming task for large HTML pages. In addition, the person in charge of web content has to ask developers to make all updates. To this end, people are looking for this better solution.
JSP is here!
JSP 0.90 appears. In this technique you can embed Java code into HTML files and the server will automatically create a servlet for the page. JSP is considered an easy way to write servlets. All HTML can be obtained directly without having to call it through (), while the person responsible for the content of the page can directly modify the HTML without risking breaking the Java code.
However, having page art designers and developers work on the same file is not ideal, and having Java embed HTML proves as embarrassing as embed HTML in Java. Reading a bunch of messy code is still a difficult thing.
As a result, people have become mature in using jsp and use more JavaBeans. Beans contains the business logic required by jsp. Most of the code in JSP can be taken out and put into beans, leaving only a few marks for calling beans.
Recently, people have begun to think that JSP pages in this way are really like views. They become a component for displaying the results of client requests. So people will wonder, why not send requests to the view directly? What if the target view is inappropriate for the request? After all, many requests have multiple possibilities to obtain a result view. For example, the same request may produce a successful page, a database exception error report, or an error report with missing parameters. The same request may produce an English page or a Spanish page, depending on the client's locale. Why does the client have to send the request directly to the view? Why should the client not send the request to some common server components and let the server decide the return of the JSP view?
This has led many 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 business logic and generates a similar data "model" for display. This data is then sent internally to a JSP "view" for display, so that the JSP page looks like a normal embedded JavaBean. The appropriate JSP page can be selected for display based on the internal logic of the servlet responsible for control. In this way, the JSP file becomes a beautiful template view. This is another development and has been praised by other developers to this day.
Enter Template Engines
Using template engine instead of JSP for the usual purpose, the next design will become simpler, the syntax is simpler, the error information is easier to read, and the tools are more user-friendly. Some companies have made such engines, most notably WebMacro (, from Semiotek), whose engines are free.
Developers should understand that choosing a template engine to replace JSP provides some technical advantages, which is also some of the shortcomings of jsp:
Question #1: Java code is too templated
Although considered a bad design, JSP still tries to add Java code to web pages. This is somewhat like Java once made, that is, simplified modifications to C++, and template engines also simplify it by removing the lower-level source code in jsp. Template engines have implemented better designs.
Question #2: Require Java code
In the JSP page, you require some Java code to be written. For example, suppose a page wants to determine the context of the root in the current web application to guide its homepage,
In JSP, it is best to use the following Java code:
＜a href="＜%= () %＞/"＞Home page＜/a＞
You can try to avoid Java code and use the <jsp:getProperty> tag but this will give you six hard-to-read strings:
＜a href="＜jsp:getProperty name="request"
property="contextPath"/＞/"＞HomePage＜/a＞
Using template engine does not have Java code and ugly syntax. Here is the same requirement for writing in WebMacro:
＜a href="$;/"＞Home page＜/a＞
In WebMacro, ContextPath is a property of the $Request variable, using a Perl-like syntax. Other er template engines use other syntax types.
Let's look at another example, suppose a high-level "view" requires a cookie to record the user's default color configuration - this kind of task seems to be only done by the view rather than the servlet controller. There must be such Java code in JSP:
＜% Cookie c = new Cookie("colorscheme", "blue"); (c); %＞
There is no Java code in WebMacro:
#set $ = "blue"
As the last ion, if you want to retrieve the color configuration in the original cookie. For JSP, we can think that there is also a corresponding tool class to help, because using getCookies() to do the lower level directly will become ridiculous and difficult. In JSP:
＜% String colorscheme = (request, "colorscheme"); %＞
There is no need for tool classes in WebMacro, usually: $. For graphic artists who write JSP, which grammar is easier to learn?
JSP 1.1 introduces custom tags that allow any tags similar to HTML to execute Java code in the background in JSP pages, which will have certain value, but the premise is to have a widely known, fully functional, free-to-get standardized tag library. There is no such tag library yet.
Question #3: Simple work is still tiring
Even simple tasks, such as including header and footer, are still very difficult in JSP. Suppose there is a "header" and a "footer" template to include all pages, and each template to include the current page title in the content.
The best way to do it in JSP is:
＜% String title = "The Page Title"; %＞
＜%@ include file="/" %＞
...The content of your page...
＜%@ include file="/" %＞
Page designers should remember not to miss the semicolon on the first line and define the title as a string. Additionally, / and / must be in the root directory and must be a complete file that is accessible.
Including headers and footers in WebMacro is simpler:
#set $title = "The Page Title"
#parse ""
Your content here
#parse ""
There is no semicolon or definition of title to keep in mind for designers. The .wm file can be placed under a customizable search path.
Question #4: Very rough loop
Looping in JSP is difficult. Here we use JSP to repeatedly print out the name of each ISP object.
＜%
Enumeration e = ();
while (()) {
("The next name is ");
(((ISP)()).getName());
("＜br＞");
}
%＞
Maybe when will there be user-defined tags to do these loops. The same is true for "if". JSP pages may look weird java code. And at the same time, the webmacro loop is pretty:
#foreach $isp in $isps {
The next name is $ ＜br＞
}
The #foreach directive can be easily replaced by the custom #foreach-backwards directive if necessary.
If you use jsp, it is likely to change this: (Here is a possible <foreach> tag)
＜foreach item="isp" list="isps"＞
The next name is ＜jsp:getProperty name="isp" property="name"/＞ ＜br＞
＜/foreach＞
The designer of course chose the former.
Issue #5: Useless error message
JSP often has some surprising error messages. This is because the page is first converted into a servlet and then compiled. A good JSP tool can relatively increase the possibility of finding a location for errors, but even the best tools cannot make all error information read easily. Due to the conversion process, some errors may not be recognized by the tool at all.
For example, suppose that the JSP page needs to create a common title for all pages. The following code is not wrong:
＜% static String title = "Global title"; %＞
But Tomcat will provide the following error information:
work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Statement expected.
static int count = 0;
^
This information believes that the above script is put into the _jspService() method and static variables are not allowed to be put into the method. The syntax should be <%! %>. It is difficult for page designers to understand these error messages. Even the best platforms are not doing enough in this regard. Even if all Java code is removed from the page, it doesn't solve the problem. Also, what's wrong with the following expression?
＜% count %＞
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.
("\r\n");
^
In other words, it's just a mark lost. It should be ＜%= count %>.
Since the template engine can be generated directly in the template file without any dramatic conversion to the code, it can be very easy to give appropriate error reports. And so on, when the command in C language is stamped into the Unix shell's command line, you do not want the shell to generate a C program to run this command, but you just need the shell to simply interpret the command and execute it, and give it directly if there is any error.
Question #6: Need a compiler
JSP requires a compiler placed in the webserver. This became problematic because Sun refused to give up the library that included their javac compiler. The web server can be included in a third-party compiler such as ibm's jikes. However, such a compiler cannot work smoothly on all platforms (written in C++) and is not conducive to building a pure Java web server. JSP has a precompiled option that can work, although not perfect.
Question #7: Waste of space
JSP consumes extra memory and hard disk space. For every 30K JSP file on the server, corresponding class files larger than 30K must be generated. In fact, doubles the hard disk space. Considering that JSP files can easily include a large data file at any time by ＜%@ include＞, such attention has a very realistic significance. At the same time, the class file data of each JSP must be loaded into the server's memory, which means that the server's memory must always save the entire JSP document tree. A few JVMs have the ability to remove class file data from memory; however, programmers usually have no control over such rules to reaffirm, and reaffirmation may not be very effective for large sites. The second file is not generated for template engines, so space is saved. Template engines also provide programmers with complete control over templates cached in memory.
There are also some problems using template engine:
Template problem #1: No strict definition
How template engine works is not strictly defined. However, compared to JSP, this is actually not very important. Unlike JSP, template engines do not have any special requirements for web servers -- any server that supports servlets can support template engines (including API 2.0 servers such as Apache/JServ, which cannot fully support JSP)! If providing healthy competition for the best template engine design could have caused a dazzling innovation, especially with the promotion of open source (which can promote and promote each other), today's WebMacro will be like Perl, without strict definition but the promotion of open source organizations is its standard.
Template's Problem #2: Not recognized
Template engines are not widely known. JSP has occupied a huge commercial market and is deeply rooted in the hearts of the people. And using g template engines can only be an ununderstood alternative technology.
Template problem #3: Not yet configured
Template engines have not been highly adapted. There is no performance test and comparison between template engine and JSP. In theory, a well-provisioned template engine implementation should match a well-provisioned JSP; however, considering that the third party has made such a profound push for JSP, only JSP has been well-provisioned.
JSP roles
Of course, JSP will inevitably have its status in the future. Even in terms of names, the similarity between JSP and ASP is seen, and they only have one letter difference. So if people who use Asp turn to Java, a very similar JSSP environment will play a great role in promoting this, and the role that can be played by maintaining such a correspondence with Asp should also be the focus of the designers who launched JSSP.
However, one thing that I want to emphasize here is that it is very different for workers who are conducive to the transition to a new environment and whether it is actually the best way to use it.
JSP is increasingly showing that it is becoming one of the most important Java technologies, which will bring people out of the world of ASP - thus, Sun will support this powerful business case, and Java-related technical supporters will also provide greater support.
However, this is not the best solution for the java platform. This will make the java solution seem like there is no java solution.