As Ajax technology matures, different programming techniques emerge. In particular, over the past few years, two independent approaches to the creation of Ajax applications have emerged.
Frank Sommers talks about this interesting problem on the pages of his blog. He says that so far among the developers it has been possible to reach some consensus on what is considered an Ajax application. At the same time, there is a lot more disagreement on how to use JavaScript and how to distribute authority between the client and the server.
These are different development packages that use a different approach. Some of them, such as Dojo or Prototype, give the user complete freedom to work with JavaScript tools and are more focused on the client side. At the same time, in other development packages all JavaScript tools are “hidden” in the JSF components, and the main work is done on the server.
Russian programmer and web developer Ivan Sagalayev
talks in more detail
about these two approaches . However, he emphasizes that the two approaches are completely compatible with each other, so that they can be successfully combined. Ivan Sagalaev gives examples of such a combination.
')
The first approach to creating Ajax applications:
transferring HTML . This approach is ideal for pages that, when interacting with the server, change slightly. For example, a certain form, which, after being sent to the server, appears again on the screen, and with it some additional information appears. In this case, Ajax allows to reduce the amount of data transmitted over the network, taking from the server not the whole form with indication, but only the indication itself. The advantages of this approach is simplicity. The main drawback is that when updating more complex pages, where different parts change, you have to drive large amounts of data from client to server, and “the whole meaning of Ajax degenerates without the animation effect of the browser icon in the upper right corner,” Sagalaev writes.
The second approach to creating Ajax applications: the
transfer of structural data . This is the essence of Ajax in the traditional sense, since this method was invented just to contact the server and get a description of some part of the system state expressed in XML. The advantage of this approach is maximum flexibility. You can come up with absolutely any format and data set, which is requested from the server, which will be exactly the information that is missing on the client, and nothing superfluous. On the client, with Javascript, you can change the page as you like.
The most obvious minus in the transfer of the structure is a much larger volume and complexity of programming.
The first difficulty, according to Ivan Sagalayev, is the use of XML. Despite the fact that the format is clear and wonderful, in Javascript you can work with it only with the help of DOM methods. However, this particular flaw has recently been solved using the JSON format: data is returned from the server not in the form of XML, but in the form of Javascript code.
The second difficulty: building HTML completely manually using DOM methods. But the worst thing is that with this, two completely different sections appear in the system, in which the page type is defined: HTML template and Javascript code.
According to Sagalayev, the two “incompatible” approaches to creating Ajax applications can be easily combined, if you do not limit yourself to using only XML. The following methods are used:
* the response from the server is transmitted as a JSON object;
* things not related to HTML generation are performed by the script, using data from the object;
* if you need to change some unusual sections of HTML, then they are transmitted in lines in the same object;
* resizable parts of HTML on the server are designed as small include templates and are used both in the initial formation of the page and in Ajax responses.
“The only thing that I don’t like about this approach so far is that the amount of work on the server side is somewhat increasing,” Ivan
concludes in his Maniacal Weblog.