JSP/servlet/JSF: javaee no longer requires Ajax

Author: thesixthday, source: CCID technical community, responsible editor: Li Chunyu,

After receiving the response, the browser no longer needs to render and refresh the entire page. Instead, it only needs to execute this script and update the page control. A better way is to provide a tree component that supports ajax to reduce the transmission of redundant data.

Three years ago, Rod. Johnson, father of spring, wrote a book that caused a sensation in the Java field: Expert
One-on-one J2EE development
EJB. This book describes the significance and value of EJB as the core technology of J2EE, but the author introduces some defects and shortcomings of EJB in a larger space, and puts forward
The EJB solution. It is precisely because of the exciting slogan "J2EE without EJB" and the foundation laid by this book that spring
The birth of the classic Lightweight Framework.

Two years ago, Ajax began to enter people's field of view. So far, Ajax has become a thriving technology. But today, I want to say: javaee without Ajax.

　"Original Sin" of AJAX"

Why Is Ajax so red? Some people say that it is because of an easy-to-remember name (such as the famous Dutch Ajax team, Ajax); others also say that it is because Google's brand new
Ajax application products bring people a cool experience (such as the great Google
Maps, Gmail, etc ). Indeed, the main reason why Ajax is so popular is that it brings a better user experience and changes the bad impression of traditional Web applications.

However, even the Ajax craze fans have to admit that, technically, Ajax has not brought anything new. It is essentially a new technology for bottled old wine,
The advantage is that
Script and DHTML provide an asynchronous programming model, which enables web applications to provide a better human-machine experience for customers. As the plain text "ajax" that I argued last year is just
As stated in the ferry technology, Ajax has a low level of problem solving. In other words, it is difficult to form a highly abstract framework-level solution to solve the problem. In addition, Ajax is based on
Java Script, so it is inevitable to introduce many disadvantages of Java Script, such:

Cross-browser is a nightmare

Poor Support for search engines

Killed back, history, and other buttons (although I don't think back or history is a good thing)

High development and maintenance costs

Java, not Java Script

We love Java, not Java Script. Mao Zedong's common sentence is: "Java, not Java Script ". I believe many readers may disagree with this title, but this sentence represents the voice of many J2EE developers.

Many Java engineers are almost paranoid about Java. They love Java's conciseness and elegance. However, once they perform Java
The development of scripts is often at a loss: over-flexible syntax, syntax validation through the compiler, lack of good debugging tools, etc.
Script is awesome, let alone Ajax development.

In a word, the Java Community needs ajax to improve the human-machine experience of javaee-based Web applications. However, people do not like the current development mode of Ajax. Undoubtedly, we need a new solution.

　　Who will save javaee's Ajax?

The answer I provided is JSF. Currently, a popular saying about JSF is "Tragic Life: sun makes JSF come to the Java Web world with its bare body ". However, my opinion is: as a revolutionary server-side component technology, JSF is like the sun at nine o'clock AM, and its future is limitless.

Let's talk about the facts. Let's take a look at the standard lifecycle of the JSF request/response process:

　　

Figure 1: JSF Lifecycle

It can be observed that any JSF "Faces request" request goes through restore view and apply request
After the values, process validations, update models, and invoke application stages,
"Render response" is returned to the client. So how does the conventional JSF engine implement the above process?

After receiving the response, the browser no longer needs to render and refresh the entire page. Instead, it only needs to execute the script content and update the page control. A better way is to provide a tree component that supports ajax to reduce the transmission of redundant data.

　　

Figure 2: request and response processes of the regular JSF Engine

Review the regular JSF engine's request and response process: first, the client requests a resource to generate a faces
After receiving the request, the server generates a faces
Response. We noticed that the Content-Type of the response is text/html, And the generated content is a piece of HTML text. The browser receives HTML text
Later, the entire page will be rendered and refreshed.

Ajax enabled applications that do not need to write Ajax code

I use the self-developed JSF engine to handle the above process (see www.operamasks.org for details), as shown in:

　　

Figure 3: request and response processes implemented by operamasks JSF

First, we can see that faces request is sent based on "X-requested-by: XML HTTP
Request ", that is, this is an Ajax request. After the request arrives at the server end, the server side will generate the faces response, which is the same as the regular faces
Response has also changed: Content-Type is no longer text/html, but changed to text/JavaScript. In addition, the response body is no longer
It is HTML text, but a bunch of script scripts. After receiving the response, the browser no longer needs to render and refresh the entire page. Instead, it only needs to execute the script content and
.

Obviously, through the above JSF technology, we have obtained:

Ajax-based request, response, and page Control update

Significantly reduced data transmission volume

Avoid refreshing the entire page for better user experience

System agility and Efficiency

In other words, any standard JSF application only needs to run it on the operamasks JSF engine to achieve this effect. We didn't write any line of Ajax code, but our application is a natural Ajax enabled application. The greatest truths are simple and the elephants are invisible.

Secret: JSF's render Mechanism

Why?

The JSF component is only a carrier of specific States and behaviors. The form in which the component interacts with the user is completely customizable and independent of the specific language, which can be HTML, WML, or
Other forms; specifically, it can be implemented by specifying the render kit of the JSF component, and each render
Kit, which corresponds to a series of render in the same style and form written by the component author.

For example, if you want to implement chart functions on a webpage, MSIE has VML, Gecko, and opera have SVG, while on the server side, you only need to simply judge the browser type, you can select a render kit to generate different client performances to complete the same function-this is a task that is difficult to accomplish with conventional JSP technology.

In layman's terms, JSF components can be translated into any form you want. So and JSF frameworks are more powerful than other open-source frameworks. Operamasks JSF described above, its container-level Ajax implementation, is a specific case of flexible application of render kit.

JSF engine supported by Ajax at the container level

The JSF we proposed is directly handled by the JSF container for Ajax requests. It will determine whether this is a normal HTTP request or
Ajax request: if it is a regular HTTP request, run the JSP page to generate the page document (specific, for Ajax render
Kit, add some basic Ajax JavaScript code); if it is an Ajax request, the server decodes the request parameters normally and executes all of its
Generate a JSF component tree.

Until this step, the processing method is exactly the same as that for common HTTP requests. The only difference is that
In the response stage, the container not only calls the Ajax function written by the component author
In addition to Renderer, more importantly, when a response page is generated, all static content that will not change will be filtered-that is, static content will not be generated in the response page, for every dynamic content
A corresponding JavaScript code is generated (which can be further optimized to be processed only when the dynamic content is changed ). In this way, the Ajax response sent to the customer is actually caused
Javascript statements. When the Ajax response is returned to the client, the Ajax callback function can automatically execute these JavaScript statements to complete the real-time, partial
Instead of refreshing the entire page. Depending on the specific functions of the JSF component, you can even change the appearance of the page. The entire Ajax mechanism is provided by the JSF engine and completely transparent to users.

In fact, in the JSF specification, the render Kit Used in the JSF page output phase is replaceable. The default html_basic render
Kit outputs standard HTML syntax and does not contain any Java script code. The JSF engine we proposed implements an Ajax render
Java Script code can be embedded in HTML documents to implement Ajax features. To replace render kit, you only need to modify the configuration file.

To put it simply, this JSF engine implements the corresponding Ajax render for each standard component. For example, for the uicommand component, its Ajax
Render adds JavaScript Ajax code to The onclick event to submit Ajax requests to the server. In this way, any one contains a standard JSF Group
You can modify only the configuration of the render kit to Ajax to implement Ajax for Web applications. Third-party components may not be supported by themselves.
Ajax, but with a tag named, you can immediately convert this third-party component to Ajax enabled.

For example, Apache
The Tomahawk project of MyFaces provides a tree component that does not support Ajax. The entire page is refreshed every time a tree node is pressed. Use tags
Then, only the tree part is refreshed without refreshing the other part of the page. Of course, a better way is to provide a tree component that supports ajax to reduce the transmission of redundant data. About the original tag
If you are interested, refer to the source code of operamasks JSF (see references.

In summary, javaee requires Ajax, but does not need the traditional Ajax development mode. Through our operamasks JSF technology, we no longer need to know what Ajax is, but our application is a natural Ajax enabled application.

Therefore, we think that javaee without Ajax!