I think JSP has a problem (the next)

js| problem I think JSP has a problem (next)
(Author: Small Longting main Blueski compiled December 22, 2000 14:22)

(Continuation of the article)

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:

<% 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 rough cycle

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 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:

<% 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 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.

< finished full >