1 page-Level rendering
In the new web, the front-end and back-end interaction, very straightforward, browser-side issued a URL, back-end returned a spelled HTML string. Browser to render it. There may be some PHP mixed in HTML (or some HTML in PHP). Assemble data and templates on the server side to generate an HTML string to return to the browser end.
This is no different from what we are doing on a regular web page. Only now, we use template technology more often to solve the problem of the front and back coupling.
The front end uses the template engine to write some tags in html, which is essentially irrelevant to the data and logic. The backend, when rendered, parses the tags and generates HTML strings, such as Smarty. In fact, the front-end and back-end interaction in the service side has been once.
Front.tpl
<div>
{% $a%}
</div>
Back end:
Setting variables
$smarty->assign (' A ', ' give data ');
Show Template
$smarty->display ("Front.tpl");
To the front end is a rendered good HTML string:
<div>
Give data
</div> Copy code This way is characterized by the display of data quickly, directly back-end assembled data and templates, to show to the user.
2 asynchronous requests and new templates
The new era, led by Ajax. (Asynchronous Javascript and XML), the history of this technology, I will not repeat. There are also many uses of Ajax.
Ajax accepts various types of returns. including xml/json/string and so on. The front-end initiates an AJAX request, and the backend returns the data directly.
But has the reader ever wondered what the AJAX data is for? It is believed that most people use Ajax to get back the data that is used for display. The front-end has to take the Ajax back data and templates to assemble. This faces a problem when your template is very "gorgeous" (that is, when the template code is much more). The logic of the spelling string we write on the front end can be very complicated.
Also some people diagram, directly in the Ajax return value, the transfer of the assembled HTML string. This enables you to populate the page with an HTML string that you get Ajax directly.
The following examples illustrate two ways:
2.1 Ajax get string Direct rendering method
As shown in Figure 2.1.1:
Index.html
<! DOCTYPE html>
<meta charset= "Utf-8"/>
<body>
<div class= "Blankplace" ></div>
<script>
var xhr = new XMLHttpRequest ();
Xhr.onreadystatechange = function () {
if (xhr.readystate = = 4 && xhr.status >= && xhr.status < 300) {
Document.queryselector ('. Blankplace '). InnerHTML = Xhr.responsetext;
}
};
Xhr.open (' Get ', './a.html ');
Xhr.send (NULL);
</script>
</body>
========================================================================
A.html
<div> This is the request back data </div> Copy code I'm the template
This is the requested data.
Figure 2.1.1
2.2 Ajax to get data, the way the front-end is assembled
<! DOCTYPE html>
<meta charset= "Utf-8"/>
<body>
<div class= "Blankplace" ></div>
<script>
var xhr = new XMLHttpRequest ();
Xhr.onreadystatechange = function () {
if (xhr.readystate = = 4 && xhr.status >= && xhr.status < 300) {
var res = json.parse (xhr.responsetext);
Document.queryselector ('. Blankplace '). InnerHTML = '
+ ' ' I am the template ' +
' ' <div> ' +
res.data+
' </div> ';
}
};
Xhr.open (' Get ', './b.json ');
Xhr.send (NULL);
</script>
</body>
Figure 2.2.1
2.3 Trade-offs in two ways
So how do you weigh the two ways?
The author of the list from their own thinking, draw the following conclusions. If the assembly of this template occurs many times. is a very frequent behavior, and the template is basically consistent, only data changes, it is best to start with a client-side assembly method. Because the same template is not necessary to be uploaded to the client several times. In this way, we can have the traffic that transmits the same template, and the request is faster.
Similar to the news stream this kind of website is more suitable for this kind of way, like today's headline, as shown in Figure 2.3.1:
Figure 2.3.1
Figure 2.3.2
The author after the Dom hit a breakpoint, found its assembly template, it is done at the client.
However, this practice also has a problem, that is, the user synchronized refresh, the need for such a page rendering finished, and then send a request, to request the first screen of data to start rendering. This process is equivalent to two requests, while the waiting is still perceptible, as shown in Figure 2.3.3.
Figure 2.3.3
So this way is also a bit unsatisfactory place. After viewing, NetEase news Web version, today's headline
