The browser uses AJAX, and the server returns json data. The mode of updating the view without refreshing has been used for a long time in WEB development. I remember that it was first used in 2008, when JSON data was passed to me. This method only needs to use the toolkit to serialize the model into the json format. The js UI library can always recognize this format and easily generate new view fragments.
However, times have changed. This way of transferring AJAX JSON has gradually encountered new problems.
- The JSON serialization library cannot serialize model objects perfectly. The serialization library always expects to input one object, but actually the front-end may need multiple objects, so you have to create another object dedicated to serialization. In addition, the serialization logic is very simple, that is, all object properties are serialized. Although JSON Lib can provide attribute filtering, attribute formatting, etc., it is far less perfect than template rendering. Template language provides rich statements and extensions to handle model objects. In addition, JSON Lib references each other in serialized objects, which is not handled well. In the template language, this will not be a problem. In a word, developers have to create new view objects in order to serialize JSON, and have to invade the original model to specify the serialization logic. Take the FastJSON tool that I think is the best as the column, you can see the questions asked by various developers (I directly find the latest posts from the fastjson forum line)
-How to make the null value in the map equal to "" when using fastjson to convert to map
-FastJson 1.2.4 Date type ISO8601 format serialization problem
-It is suggested that @ JSONType annotation add the allows attribute and allow to set the number of attributes allowed to be serialized (Note by the author: I also recommend other annotations to control the rendering logic. In fact, due to the lack of language features, fastJson will be overwhelmed by such similar rendering logic suggestions)
-Fastjson supports escape to prevent xss?
With the development of front-end technology, programmers no longer need easyui, extjs, a front-end framework. Because this frame is not visual centered, the visual personnel cannot control this frame. Now the more popular way is template, which is only done through the front-end template engine: the input is JSON and front-end template, and the output is the updated DOM. Then the problem arises. Is this better than direct back-end template engine rendering? Why bother to serialize it into json, and then render it with a weak front-end template engine. It's a bit of a taste of seeking distance.
3. For some websites that need SEO, using AJAX JSON is a fatal problem, because the search engine cannot execute javascript, and the pages picked up are empty shells. Very unfriendly. At present, there is no good way. It is said that one is still using ajax, but will provide an invisible url to search engines to provide correct content. In addition, it is said that Google search engine has a special simulator to simulate the execution of javascript to obtain SEO content, but it is under development.
4 For a complex page, if multiple parts are requested by AJAX, it will kill the Web server. Now the server is not afraid of CPU busy, but afraid of many requests. Therefore, AJAX JSON is also very difficult to use in complex pages. The result is that the complexity of the server is multiplied, and the real content of the page cannot be loaded. There is also no way to improve it.
After complaining about so many AJAX+JSON, it's time to talk about how Beetl solved it.
Beetl's solution is Ajax+HTML fragments, which is not new, but Beetl has its own unique solution. Beetl has introduced a new syntax tag # ajax This syntax only marks a section of template block, followed by an id representing the name of the ajax section. If the template renders the view normally, the template engine will ignore the # ajax tag and render all the contents of the template normally. If the rendered view has a # id, such as index. html # top10, the template engine will only render the content marked by # ajax top10. The following index.html template:
Other contents of the page ....... <div id="top10"> %> #ajax top10: { <#table data="${topData}" var ="row,index"> <# tr name="name">${row. name}<# tr> <# tr name="Integral">${row. score}<# tr> </#table> <#page data="${topData}" url="/indexTop10.html"/> <%} //end ajax top 10 %> </div> ...... Other contents of the page
This template contains many parts. Only the ajax part is listed here. The ajax part is a table tag or any other betl template engine code.
When the user requests the index.html page, the background controller may be like this
public String index(){ int page = this.getParameter("top10",0); this.setAttr("topData",service.getTop10(page )); //Set data required by other indexes this.setAttr("userInfo"...); this.setAttr("menu"...); return "/index.html"; }
When the user turns the page of top10, the client js will send an ajax request to/indexTop10.html. The background controller may be like this
public String indexTop10(){ int page = this.getParameter("top10",0); this.setAttr("topData",service.getTop10(page )); return "/index.html#top10"; }
Note that the template rendering view is "/index. html # top10" instead of "/index. html", which ensures that the template engine only renders top10 clips. The client only needs to call the jquery code $("# top10"). load ("/indexTop10. html? Page="+xxx) to turn pages without refreshing
Compared with the four major slots of ajax+json listed at the beginning of the article, ajax+beetl can perfectly solve the problem. The language function of template rendering template is stronger than simple object-oriented serialization, and also stronger than front-end template engine. SEO has no problem, and the page is welcomed by search engines. One rendering will not cause too much access pressure on the server. In addition, from the development perspective, the problems faced by developers are much simpler, which can improve the development efficiency.
Since Ajax+Beetl is still an improvement of Ajax+HTML, there will still be some shortcomings of the AJAX+HTML mode, such as the increase of network transmission data, and the template rendering performance will certainly be inferior to that of json serialization. If your hardware environment is tight, you need to consider this method carefully, but as far as I know, enterprise applications or web sites are not a problem. Another potential problem is ajax+json. The returned json data can be processed on the front end for many times, such as rendering multiple DOM nodes, while Ajax+beetl cannot. You can only render a Dom node first, then obtain the data you need through js, and then render other DOM nodes, but this situation is very rare
For specific examples, please refer to:
http://beetlajax.oschina.mopaas.com/
And articles written by developers: http://blog.csdn.net/hiredme/article/details/44219581
