js| problem I think JSP has a problem (on)
(Author: Small Longting main Blueski compiled December 22, 2000 14:22)
(Editor: The original text of this article first appeared in foreign countries, JSP is just a budding technology, and not as it is now in the heyday.) 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:
<a href= "<%= request.getcontextpath ()%>/index.html" >home page</a>
You can try to avoid Java code while using the <jsp:getProperty> tag, but this will give you the following string that is hard to read:
<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 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:
<% cookie C = new Cookie ("ColorScheme", "Blue"); Response.addcookie (c); %>
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:
<% 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 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.
