ActionWeb. Asynchronous Internet.

Since the first mention of AJAX in Jesse James Garrett's article “A New Approach to Web Application Development” on February 18, 2005, 4 years have passed. During this time, probably every web developer at least once tried this technology, and now it’s no longer surprising the average Internet user to dynamically validate forms, auto-complete queries in the search bar, pop-up context menu, and other recently strange web-interactive interactive joys, and modern JavaScript frameworks make the process the development of such scripts is much faster, more efficient and more pleasant for a programmer. But why so far the overwhelming majority of developed websites adhere to the standard content download model and have not switched completely to the AJAX platform? Why reload the entire page each time you click on an internal link, when you only need to change the content block, and the JavaScript files, CSS, and most of the HTML markup do not require updating?





There are several reasons:



- Each time opening a resource in the AJAX browser, the user starts working from a “starting point”, because the state of such an application in most cases is not displayed in the address bar of the browser

- Dynamically downloadable content is not processed by search robots

- Development of asynchronous web applications is much more complicated and longer than when using a static model

- Lack of integration of AJAX applications with standard browser tools. You cannot navigate through this resource using the back and forward buttons of the browser, you cannot add the page of the site to the bookmarks, if it loads dynamically, you cannot open the link to the dynamic content in a new browser tab

- The use of a “thick” client significantly increases the load on the user's computer’s processor and the required amount of RAM

- AJAX application will not work when JavaScript is disabled in the user's browser

')

To overcome the above problems, you need a completely new concept, which we call ActionWeb . At its core, ActionWeb (like AJAX at the time) does not offer new technologies, but only changes the principle of using already known ones. Let's advance the main theses of the concept:



1. the same data is not loaded more than once without special need, a full page reload occurs only in exceptional cases

2. ActionWeb application from the point of view of the user and the search engines is not different from the usual website

3. separation of the presentation layer and the business logic layer of the client part of the application

4. layer of business logic is not visible from the presentation layer, the developer from project to project changes only the presentation component



Consider the above problems AJAX applications, and mechanisms for their solution, implemented when creating the site nikitaeremin.com taking into account the use of the concept ActionWeb.



Problem: The current state of the AJAX resource is not displayed in the address bar of the browser, the user starts work every time from the "starting point".

Solution: If you change the url in the address bar of the browser, the page reloads. There is only one exception to this rule: without a reboot, you can change the hash of the address bar (location.hash), in other words, add / remove the # symbol and everything that stands behind it. In the address bar there will be something like nikitaeremin.com/#projects/persik/ , while the ActionWeb application, during initialization, extracts a hash from it and forms its state accordingly.



Problem: dynamically loaded content is not processed by search robots

Solution: when browsing a web resource, search robots do not perceive JavaScript. Scanning the source HTML code of the page, they travel by internal links, while the address nikitaeremin.com/#projects/persik/ will mean for them to go to the main page. Output-in the source code to leave the links as they are, while separating them into internal and external. You can divide, for example, by adding the css class to the link. When an ActionWeb application is initialized, event handlers are attached to the links with the specified class, which dynamically load the content and change the hash of the browser's address bar. But what will happen when a user navigates from a search engine to the link nikitaeremin.com/projects/persik/ , indexed in the source code of the ActionWeb application? A redirect to nikitaeremin.com/#projects/persik/ is placed on the corresponding page, a transition to the main page takes place and the application forms its state based on the hash of the address bar.



Problem: Lack of AJAX Application Integration with Standard Browser Tools

Solution: If you use the above technique to change the address bar, the problem of adding to bookmarks is solved by itself. It also solves the problem of the inability to open the internal link AJAX applications in a new browser tab, because in an ActionWeb application, right-clicking on the internal link, the user clicks on the normal link, and the browser works with it the same way he would work with it on a static site. You can restore the functions of the browser back and forward in two ways. The first way is to use the history plugin for jQuery, written just for this purpose, but this script does not differ in cross-browser compatibility and does not work correctly primarily in Internet Explorer. The second way is to save all changes to the address bar in the JavaScript array and, using simple manipulations, implement the back and forward buttons directly on the application page.



Problem: Developing AJAX applications is an order of magnitude more difficult than using a static model

Solution: Separation of the presentation layer and the logic layer of the client part of the application. With this approach, only the presentation component changes from project to project, all the functions of interacting with the server, receiving and processing information are “protected” inside the engine, providing a sufficient level of abstraction, and the developer does not need to think about them. Some features related to the operation of the business model of the application, such as caching loadable content pages, the name of the class for internal resource links, etc. can be configured in the JSON object passed to the engine during initialization.







Problem: The use of RIA significantly increases the load on the processor of the client computer

Solution: When using JavaScript, the processor load is mainly due to the saturation of the presentation layer, especially when several animation functions are executed simultaneously with each other or with the layerless logic layer, and if overloaded, the browser can simply “hang”. Output is the implementation of a chained function call on critical sections of the application. A chain call would not allow the execution of several functions at the same time, thereby preventing excessive load on the user's computer. But for the implementation of this mechanism in JavaScript, it is not enough to simply arrange the function calls one below the other; this simply does not work if there is at least one animation function in the sequential call list, since A JavaScript interpreter encountering time-delayed operations (in other words, timeouts) does not stop waiting for them to complete, but goes further along the code. Let's take a simple example written in jQuery. Suppose there is an animation function and a logic function, the logic function needs to be performed only after the animation function completes:

 function animation () { 	
     $ ("# elem"). animate ({"width": "300px"}, 200, "linear", function () { 
         alert ("animation first!"); 
     }) 
 }  

 function logic () { 
     alert ("logic first!"); 
 }  

 animation (); 
 logic ();

When executing the above code, the first alert will be “logic first!”, Since the completion of the animation function is delayed by time. And to achieve our goal, the code should be rewritten as follows:

 function animation () { 	
     $ ("# elem"). animate ({"width": "300px"}, 200, "linear", function () { 
         alert ("animation first!");  
         logic ();     	
     }) 
 } 

 function logic () { 	
     alert ("logic first!"); 
 }  

 animation ();

But with this approach, the 4th thesis of the ActionWeb concept would not be implemented. To implement an anonymous call of business logic functions in the Persik engine, it was necessary to write the chain method connecting the components of the business model and the presentation layer. In the business logic layer, the use of the chain method is as follows:

 engine.chain (func1, [vars1]). chain (func2, [vars2]). chain (func3, [vars3]). start ();

In this case, in each function of the chain, the exit point must be clearly defined:

 function animation () { 	
     $ ("# elem"). animate ({"width": "300px"}, 200, "linear", function () { 		
         alert ("animation first!");         		
         animation.next ();     	
     }) 
 }

 function logic () { 	
     alert ("logic first!"); 	
     logic.next ();
 } 

 persik.chain (animation) .chain (logic) .start ();

As you can see from the example, the functions of the chain do not know where they were called from or what functions they transfer control to. This approach has 2 main advantages.

1. The developer is confident that the function of the chain will begin its execution only after the previous one is completed. At the same time, he himself determines how consistent the execution of functions should be, and can place the call to next () anywhere in the animation function.

2. The principle of anonymous function call is implemented, ensuring maximum separation of the business model from the presentation layer.



Problem: AJAX application will not work when JavaScript is disabled in the user's browser

Solution: In essence, what is an ActionWeb resource? This is an interactive web application using the asynchronous data loading method, the state of which in most cases is uniquely determined by the url. What will change when you turn off javascript? The state of the application will not be generated on the client side, the possibility of asynchronous data loading will become inaccessible, the animation functions will not be performed. In this case, the application state can be generated on the server side, the final state of objects (open / closed) can be separated from the animation functions, selected into separate classes and the state of DOM objects can be created using classes (the simplest example is highlighting the current menu item), asynchronous content loading it will change to the traditional one, and as a result you will get the most common web resource in terms of architecture. On the server, it will be necessary to determine whether js is enabled in the user's browser, and based on this, issue either the ActionWeb version of the site or the usual static one. Of course, the implementation of this approach is not possible for all AJAX applications, and in the static version only functions of loading and displaying content will be available, but in the end the developer will be sure that the user is guaranteed to receive the minimum amount of site functionality, regardless of the settings of his browser.







As a result, the created resource is recognized by search robots, does not lose its working capacity when JavaScript is turned off in the user's browser, works faster with AJAX and is distinguished by high presentation appeal due to the use of JavaScript animation.