js| Problem Blueski Compilation
(Editor's note: This article through the JSP and template engines comparison, prompts the current JSP some deficiencies. The latter is also a technology based on Servlets, some similar macro, can simplify the development, but later did not receive due attention and development. ）
Today, every developer using Servlets knows JSP, a web technology that Sun invented and spent a lot of effort to implement and build on the servlet technology. 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." "(Section 1.9, 1999/12/15 listen to the opinion edition).
The purpose of this article is to hear an assessment of the reasonableness of this statement-by comparing JSP and another servlets based technology: template engines (template engine).
The problem of using servlets directly
At first, Servlets was invented and the whole world saw its superiority. A servlet-based Dynamic Web page can be executed quickly, easily transferred between multiple servers, and can be seamlessly integrated with the backend database. Servlets is widely accepted as the preferred platform for Web server-side.
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 is 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 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 to!
JSP 0.90 appears. 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 a client request. 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 might produce a successful page, a 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 shouldn't the client be sending the request to some generic server component and having the server decide on the return of 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 so far--->>
Enter Template engines
Using 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 made such engines, most notably Webmacro (http://webmacro.org, from Semiotek), whose engines are free.
Developers should be aware that the selection of a template engine to replace JSP provides such a number of technical advantages, which is the JSP's some deficiencies:
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 something 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. Template engines implemented a better design.
Problem #2: Require Java code
Require some Java code to be written in the JSP page. For example, suppose a page determines 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 your JSP:
<a href= "<%= request.getcontextpath ()%>/index.html" >home page</a>
You can try to avoid Java code while using <jsp:getProperty> tags but this will give you six hard to read strings:
<a href= "<jsp:getproperty name=" Request "
Property= "ContextPath"/>/index.html ">HomePage</a>
With template engine, there is no Java code and unsightly syntax. Here is the same request in the Webmacro in the wording:
<a href= "$Request. contextpath;/index.html" >home page</a>
In Webmacro, ContextPath as a property of the $Request variable, using Perl-like syntax. Other ER template engines use other syntax types.
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:
<% cookie C = new Cookie ("ColorScheme", "Blue"); Response.addcookie (c); %>
There is no Java code in Webmacro:
#set $Cookie. ColorScheme = "Blue"
As the last ion, if you want to retrieve the original cookie color configuration. 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:
<% String ColorScheme = Servletutils.getcookie (Request, "ColorScheme"); %>
There is no need for a tool class in Webmacro, usually:
$Cookie. Colorscheme.value
What kind of syntax is easier to learn for a graphic artist who writes 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 very 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:
<% String title = "The Page title"; %>
<%@ include file= "/header.jsp"%>
... The content of your page ...
<%@ include file= "/footer.jsp"%>
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 thick loops
Looping through a JSP is difficult. Here is a JSP to duplicate the name of each ISP object.
<%
Enumeration E = List.elements ();
while (E.hasmoreelements ()) {
Out.print ("The next name is");
Out.println ((ISP) e.nextelement ()). GetName ());
Out.print ("<br>");
}
%>
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 <br>
}
#foreach指令可被自定义的 #foreach-backwards instructions are easily replaced if necessary.
The JSP words are likely to change like 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, chooses 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:
<% static String title = "Global title"; %>
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?
<% 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.
Out.write ("\ r \ n");
^
In other words, it's just a missing tag. Should be <%= count%>.
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 has a precompiled option that can play a role, though 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 in the future will certainly 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 turn 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 JSP designers focus on.
The point to be stressed here, however, is that there is a big difference between working for a new environment and whether it is actually the best way to use the environment.
JSP is increasingly showing that it is becoming one of the most important Java technologies, allowing people to leave the world of ASPs--and sun will support this powerful business case, and support from Java-related technology supporters.
However, this is not the best solution for the Java platform. This will make the Java solution seem like there is no Java solution.
