Java EE no longer needs Ajax

Three years ago, Rod. Johnson, father of spring, wrote a book that caused a sensation in the Java industry: Expert one-on-one J2EE development without EJB.

This book describes the significance and value of EJB as the core technology of J2EE. However, the author introduces some defects and shortcomings of EJB in a larger space and proposes a solution for without EJB. It is precisely because of the exciting slogan "J2EE without EJB" and the foundation of this book that led to the birth of Spring framework, a 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, this is because Google's brand new Ajax application products bring amazing experiences (such as great Google Maps and Gmail) to people ). 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. In essence, it is a new technology for bottled old wine. The advantage is that it provides an asynchronous programming model through Java Script and DHTML, so that Web applications can bring a better human-machine experience to customers. As I mentioned in the plain text Ajax, a transitional technology that caused everyone's debate last year, 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. Besides, because Ajax is based on Java Script, many shortcomings of Java Script are inevitable, 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 develop Java scripts, they are often overwhelmed: over-flexible syntax, unable to perform syntax verification through the compiler, lack of good debugging tools, and so on, will make people afraid of java scripts, 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 has passed the restore view, apply request values, process validations, update models, and invoke application stages, A "render response" is generated and returned to the client. So how does the conventional JSF engine implement the above process?

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

Review the process of requests and responses of the conventional JSF engine: first, the client requests a resource to generate a faces request. After receiving the request, the server processes the request in the background, generate a faces response. We noticed that the response Content-Type is text/html, And the generated content is a piece of HTML text. After receiving the HTML text, the browser renders and refreshes the entire page.

　　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 to say, this is an Ajax request. After the request arrives at the server, the faces response generated by the server has also changed compared with the conventional faces response: Content-Type is no longer text/html, but changed to text/JavaScript; and, the response body is no longer 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 update the page control.

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 a specific State and behavior. The form in which the component interacts with the user is completely customizable and independent of the specific language, it can be HTML, WML, or other forms. Specifically, you can specify the render kit of the JSF component, A series of render corresponding to 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? D? D. 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 newly proposed JSF is directly handled by the JSF container for Ajax requests. It will determine whether this is a normal HTTP request or an Ajax request based on the request type: for a regular HTTP request, run the JSP page to generate the page document (for specific Ajax render kit, add some basic Ajax JavaScript code); for an Ajax request, the server decodes the request parameters normally and executes all stages except the page output phase in JSF to 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 subsequent render response stage, the container not only calls the Ajax function Renderer written by the component author, what's more, when a response page is generated, all static content that will not change will be filtered out? D? D. Static content is not generated on the response page, but a javascript code is generated for each dynamic content (it can be further optimized to process only the changed dynamic content ). In this way, the Ajax response sent to the customer is actually composed of such JavaScript statements. When an Ajax response is returned to the client, the Ajax callback function can automatically execute these JavaScript statements to complete real-time and partial changes to the page without 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 stage can be replaced. 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 kit. You can embed Java script code in the HTML document to implement Ajax features. To replace the render kit, you only need to modify the configuration file.

Simply put, this JSF engine implements the corresponding Ajax render for each standard component. For example, for the uicommand component, its Ajax render will add JavaScript Ajax commit code to The onclick event, submit an Ajax request to the server. In this way, any web application that contains the standard JSF component can achieve Ajax of the Web application by changing only the render kit configuration to Ajax. Third-party components may not support Ajax, but with a tag named, you can immediately convert this third-party component to Ajax enabled.

For example, the Tomahawk project of Apache MyFaces provides a tree component, which does not support Ajax itself. The entire page is refreshed every time a tree node is pressed. After the label is used, 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. For more information about the label principle, see operamasks JSF source code.

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!