Overview
Overview of the AjaxUI features and design considerations.
About the AjaxUI
In version 6.3 we are introduced a new method for loading pages that uses AJAX to load the html content rather than doing a full page refresh. This has some major benefits regarding performance such as:
Reduced server load
The server no longer has to render the header, footer, or check the standard javascript, image, and style files on each request. Only the initial load will render these elements.
No Full Rebuild of the Dom
Rather than destroying and rebuilding the entire Dom tree, only the center content area is updated.
Script Files are not Parsed
Normally when a page is loaded, even if the javascript files are cached, the browser must reload into memory and parse all of the script files. Sugar uses a very large amount of base javascript that remains the same on each page. By only parsing the javascript specific to the current page, a huge performance boost is gained. This is especially noticeable on machines with fast net connections but slow drive/cpu speeds.
Fewer Requests Per Page
When a web server is configured to for very large cache timeouts, this isn’t a very big deal. The client will only load the script, image, and style files once and never make a request for them again until Sugar is updated. However, many servers are not configured this way and the client will make a request to the server, even if it is just to verify the cache isn’t out of date for every single resource on a page. This can mean up to 100 requests for some pages. With the AjaxUI, these files stay in memory until the user closes the browser even if the cache expire is not configured. For a connection with a high ping rate, it can decrease page load time from tens of seconds for 50 requests down to a single request taking under a second.
Side Effects
There are some side effects of the AjaxUI that can cause issues with customizations.
document.write
Because the Dom has already “fully loaded” when the page is rendered, any custom javascript that uses document.write will replace the current content instead of appending to the current page. The best practice here is to use Dom Manipulation or at worst, append to document.body.innerHTML - but this is also not recommended.
onLoad
Similar to document.write, this event is no longer reliable because the page has already “loaded” before the main content is inserted. If your javascript relies on some content in the page to finish rendering before it can fire, you should wrap your code with YAHOO.util.Event.onContentReady.
Page Order vs Execution Order
One final javascript issue is the order of execution of script blocks. This isn’t always a problem but it tends to be browser specific. If for instance you wanted to use jquery and your code looked something like this:
<script type="text/javascript" src="include/javascript/jquery.js" />
<script type="text/javascript">
$("#myDiv").append("Hello World");
</script>
You cannot guarantee that the second bock will fire after jquery has loaded. To help with this problem, we’ve added a function to Sugar called SUGAR.util.doWhen. It has an signature similar to onContentReady except that instead of only wait for Dom elements to appear, it can wait for any condition to be true. The first parameter can either be a string to be evaluated or a function to call, but as soon as either is true, the function passed as the second parameter is fired. So using doWhen, the above block could either look like:
<script type="text/javascript" src="include/javascript/jquery.js" />
<script type="text/javascript">
SUGAR.util.doWhen("typeof $ != 'undefined'", function(){
$("#myDiv").append("Hello World");
});
</script>
or
<script type="text/javascript" src="include/javascript/jquery.js" />
<script type="text/javascript">
SUGAR.util.doWhen(function(){ return (typeof $ != 'undefined')}, function(){
$("#myDiv").append("Hello World");
});
</script>
or even
<script type="text/javascript" src="include/javascript/jquery.js" />
<script type="text/javascript">
var checkJQLoaded = function(){ return (typeof $ != 'undefined')};
var myScope = {target:"#myDiv"};
SUGAR.util.doWhen(checkJQLoaded, function(toAppend){
$(this.target).append(toAppend);
}, "Hello World", myScope);
</script>
JSON Responses
The final thing to watch out for is php warnings and errors causing invalid server responses. These kinds of errors being displayed won’t cause the same level of headache with a normal UI as the user can often just ignore them and continue until the admin gets around to fixing them. With the AjaxUI, the errors can cause the server response to become invalid and the page fail to load entirely. On a production instance these errors and warnings should be logged rather than shown to the user anyhow. Also, if you have a customization that tries to bypass the MVC Controller and send content directly, it could also cause display issues.
