Every developer who uses servlets today knows JSP, a web technology invented by Sun Microsystems and spent a lot of effort to promote and build on servlet technology. JSP detaches the HTML code from the servlet, thereby speeding up web application development and page maintenance. In fact, the official "Application Development Model" document published by Sun goes even 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 version).
The purpose of this article is to hear an assessment of the plausibility of this statement -- by comparing JSP to another servlets-based technology: template engines.
Problems with using Servlets directly
Initially, 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 back-end 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 the programmer to call out.println() for each line of HTML, which has become a serious problem in actual servlet applications. HTML content has to be implemented through code, which is a tedious and time-consuming task for large HTML pages. Additionally, the people responsible for the web content had to hire developers to make all the updates. For this reason, people are looking for a better solution.
JSP arrives!
JSP 0.90 appeared. In this technique you embed Java code into an HTML file 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 out.println(), and the person responsible for the page content can modify the HTML directly without risking breaking the Java code.
However, having page artists and developers working on the same file was not ideal, and embedding Java into HTML proved to be as embarrassing as embedding HTML into Java. It's still difficult to read a mess of code.
As a result, people became mature in using jsp and used JavaBeans more. Beans contain the business logic code required by jsp. Most of the code in JSP can be taken out and put into the bean, leaving only a very small amount of markup for calling the bean.
Recently, people have begun to think that JSP pages in this way are really like views. They become a component used to display the results of client requests. So people will think, why not send a request directly to the view? What happens if the target view is not suitable for the request? After all, many requests have multiple possibilities to obtain the result view. For example, the same request may produce a successful page, a database exception error report, or an error report of missing parameters. The same request may produce an English page or a Spanish page, depending on the client's locale. Why must the client send the request directly to the view? Why shouldn't the client send the request to some generic server component and let the server decide what the JSP view returns?
This has led many people to accept what has become known as "Model 2" Design, this is a model-view-controller based model defined in JSP 0.92. In this design, requests are sent to a servlet controller, which performs the business logic and generates a similar data "model" for display. This data is then sent internally to a JSP "view" for display, making the JSP page look like a regular 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
and use template engine to replace the general purpose JSP. The subsequent design will become simpler, the syntax will be simpler, the error message will be easier to read, and the tools will be better. More user-friendly. Several companies have made such engines, the most famous is probably WebMacro ( http://webmacro.org , from Semiotek), and their engine is free.
Developers should understand that choosing a template engine to replace JSP provides such technical advantages, which are also some of the shortcomings of jsp:
Problem #1: Java code is too templated
. Although it is considered a bad design, JSP still attempts to add Java code to the web page. This is somewhat like what Java once did, which was a simplified modification of C++. Template engines also simplified it by removing the lower-level source code in jsp. Template engines implement better design.
Question #2: Requiring Java Code
It is required to write some Java code in the JSP page. For example, suppose a page determines the root context of the current web application and leads to its home page.
It is best to use the following Java code in JSP:
＜a href="＜%= request.getContextPath() %＞/index.html"＞Home page＜/a＞
You could try to avoid Java code and use the <jsp:getProperty> tag but that would give you six unreadable strings:
<a href="<jsp:getProperty name="request"
property="contextPath"/＞/index.html"＞HomePage＜/a＞
Using template engine, there is no Java code and ugly syntax. Here is how it is written in WebMacro under the same requirements:
＜a href="$Request.ContextPath ;/index.html">Home page</a>
In WebMacro, ContextPath is used as an attribute of the $Request variable, using Perl-like syntax. Other 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 - this task seems likely to be completed by the view rather than the servlet controller. There must be such Java code in JSP:
<% 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 color configuration in the original cookie. For JSP, we can think of a corresponding tool class to help, because it would become ridiculous and difficult to do such low-level things directly with getCookies(). In JSP:
<% String colorscheme = ServletUtils.getCookie(request, "colorscheme"); %>
There is no need for tool classes in WebMacro, usually: $Cookie.colorscheme.Value. For graphic artists who write JSP, which syntax is easier to learn?
JSP 1.1 introduced custom tags that allow arbitrary HTML-like tags to execute Java code in the background in JSP pages. This will have some value, but only if there is a widely known, full-featured, Freely available, standardized tag library. There is currently no such tag library.
Problem #3: Simple tasks are still tiring
Even simple tasks, such as including headers and footers, are still very difficult in JSP. Suppose there is a "header" and a "footer" template to be included in all pages, and each template should contain the current page title in the content.
The best way in JSP is:
＜% String title = "The Page Title"; %＞
＜%@ include file="/header.jsp" %＞
...your page content...
＜%@ include file="/footer.jsp" %＞
Page designers should remember not to omit the semicolon in the first line and define the title as a string. Additionally, /header.jsp and /footer.jsp must be in the root directory and must be fully accessible files.
Including headers and footers in WebMacro is relatively simple:
#set $title = "The Page Title"
#parse "header.wm"
Your content here
#parse "footer.wm"
There are no semicolons or title definitions for designers to remember, and the .wm files can be placed in a customizable search path.
Problem #4: Very thick loops
Looping in JSP is difficult. Here, JSP is used to repeatedly print out 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 sometime. The same goes for "if". JSP pages may look like weird Java code. And at the same time, the webmacro loop is beautiful:
#foreach $isp in $isps {
The next name is $isp.Name <br>
}
If necessary, the #foreach directive can be easily replaced by a custom #foreach-backwards directive.
If you use jsp, it may become 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 will naturally choose the former.
Problem #5: Useless Error Messages
JSPs often have some surprising error messages. This is because the page is first converted into a servlet and then compiled. Good JSP tools can relatively increase the likelihood of finding the location of an error, but even the best tools cannot make all error messages easily readable. Due to the conversion process, some errors may be impossible for the tool to identify.
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"; %＞
But Tomcat will provide the following error message:
work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Statement expected.
static int count = 0;
^
This information thinks 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 read these error messages. Even the best platforms fall short in this regard. Even moving all the Java code out of the page 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.
out.write("rn");
^
In other words, it's just a missing mark. It should be <%= count %>.
Since the template engine can be generated directly from the template file without any dramatic translation into code, it is very easy to give appropriate error reporting. By analogy, when a C language command is typed into the command line of the Unix shell, you do not want the shell to generate a C program to run the command, but you just need the shell to simply interpret the command and execute it, and directly report any errors. out.
Problem #6: Needing a Compiler
JSP requires a compiler placed in the webserver. This became problematic because Sun refused to give up the tools.jar library that contained their javac compiler. The web server can include 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 building a pure Java web server. JSP has a precompilation option that helps, although it's not perfect.
Problem #7: Waste of Space
JSP consumes extra memory and hard disk space. For every 30K JSP file on the server, a corresponding class file larger than 30K must be generated. Effectively doubles the hard drive space. Considering that a JSP file can easily include a large data file through <%@ include> at any time, this concern has very practical 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 save the entire JSP document tree forever. A few JVMs have the ability to move class file data from memory; however, the programmer usually has no control over the rules for redeclaration, and redeclaration may not be very efficient for large sites. For template engines, space is saved because no second file is generated. Template engines also provide programmers with complete control over how templates are cached in memory.
There are also some problems with using the template engine:
Template problem #1: It is not strictly defined
How the template engine should work 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 the web server - any server that supports servlets can support template engines (including API 2.0 servers such as Apache/ JServ, they don't fully support JSP)! If healthy competition for the best template engine design could have caused a dazzling innovation, especially with the promotion of open source, (allowing ideas to push and promote each other), then Today's WebMacro will be like Perl. It is not strictly defined but the promotion of open source organizations is its standard.
Template 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. The use of g template engines can only be an alternative technology that is not understood.
Template Problem #3: Not Deployed
Template engines are not yet highly configured. There is no performance testing and comparison between template engine and JSP. In theory, a well-deployed template engine implementation should match a well-deployed JSP; however, considering that third parties have made such a profound push for jsp, only jsp is well deployed.
The role of JSP
Of course, JSP will certainly have its place in the future. The similarity between JSP and ASP can be seen even from the names, they only differ by one letter. Therefore, if people who use ASP are to switch to Java, the very similar JSP environment will play a great role in promoting this. The role of maintaining this corresponding relationship with ASP should also be a key consideration for designers who launch JSP. Arrived.
The point here, however, is that there is a big difference between what benefits workers moving into a new environment and whether it is actually the best way to use that environment.
JSP is increasingly showing that it is becoming one of the most important Java technologies, and it allows people to leave the world of ASP - thus, Sun will support this strong business case, and Java-related technology supporters will also give greater support .
However, this is not the best solution for the java platform. This will make the Java solution appear to be a solution without Java.