1.3 UI AJAX

Document created by resplin Employee on Jun 6, 2015
Version 1Show Document
  • View in full screen mode

Obsolete Pages{{Obsolete}}The official documentation is at: http://docs.alfresco.com
1.3
Archived


Introduction


Without a doubt AJAX can make a web application for responsive and more desirable to use, but we have to be careful with it's use and not go over the top. Used in the right place it can be very effective.

This page contains the results of a short investigation into some of major AJAX toolkits and frameworks around at the moment and how easy it would be to integrate them into the existing web client.


AJAX and JSF


There is one major problem using AJAX with JSF, the component model. JSF maintains the state of the component model on the server side, which always stays in synch with the client representation. If the client model changes without JSF knowing it's component model will be out of date which will certainly result in bugs and potentially data loss.

There are therefore two approaches to integrating the technologies, the non-invasive approach where AJAX is just used to complement the user experience i.e. providing a list of suggested values, determining if a space name already exists as the user types or a repository browse tool or the full integration approach where an AJAX request executes the full JSF lifecycle so that it's component model can be kept in sync with the client. An example here could be a tab component, in order for JSF to know which components are visible and could potentially provide values from the user, the server side model will need to be updated every time the user changes tab focus.

The full integration approach obviously involves a lot more work as a vast amount of JSF customisation will likely be required.


Toolkits and Frameworks


The following toolkits and frameworks will be investigated:


Are there any others people know about that should also be reviewed?

Other sugestions:


Results


The following sections give an overview of how the integration with the web client would work, how easy it was and the features of the toolkit or framework.

A simple example was used to test the integration, as the user types in the name field in the create space dialog a check is performed to see if a space with that name already exists. If it does a warning message is displayed and the OK button disabled.


DWR


DWR is a Java focused AJAX toolkit, it provides a servlet to return data from server side methods and a lightweight JavaScript library to make the remote calls. There is also limited support for manipulating the client side DOM.

The objects and methods to expose from the server are configured in a dwr.xml file. This file also acts as a JavaScript generation tool. For each object specified in the config file a 'virtual' JavaScript script is generated. The generated script contains a pseudo object representing the server side version. For example if you configured the Java class to be exposed...



public class AjaxBean
{
   public String sayHello(String name)
   {
      return 'Hello ' + name;
   }
}

...an AjaxBean JavaScript object with a sayHello() method will be available on the client to call, for example:



<script type='text/javascript' src='/alfresco/dwr/interface/AjaxBean.js'> </script>
<script>
   function test()
   {
      AjaxBean.sayHello('Gavin', callbackFunction);
   }

   function callbackFunction(result)
   {
      // update the page with the message
   }
</script>

DWR does provide integrations for several other technologies including Spring and JSF. After a bug in the JSF integration (which has gone in their latest codeline) was fixed an Alfresco JSF managed bean was exposed to the client and used to check whether the current space name in the UI existed.

The client side code for the simple example is shown below:



<script type='text/javascript' src='/alfresco/dwr/interface/AjaxBean.js'> </script>
<script type='text/javascript' src='/alfresco/dwr/engine.js'> </script>
<script type='text/javascript' src='/alfresco/dwr/util.js'> </script>

<script language='JavaScript1.2'>
function sendAjaxRequest()
{
   AjaxBean.spaceNameExists(document.getElementById('dialog:dialog-body:name').value, checkExists);
}
  
function checkExists(result)
{
   if (result == true)
   {
      document.getElementById('name-info').innerHTML = 'A space with this name already exists!';
   }
   else
   {
      document.getElementById('name-info').innerHTML = '';
   }
}
</script>

dojo


The dojo toolkit is JavaScript focused, in fact it provides no server side support at all. dojo goes far beyond AJAX, the io library is only a small part of it's capabilities, it provides a whole suite of JavaScript utilities for manipulating the DOM, a set of widgets, animation support, cryptographic support to name but a few.

In order to call server side methods with dojo the dojo.js must be included on the required page(s). The following code was used for the example:



dojo.io.bind({url: '/alfresco/mabon/mabon:AjaxBean.spaceNameExists/<timestamp>',
              mimetype: 'text/plain'
              load: function(type, data, evt)
                    {
                       if (data == 'true')
                       {
                          document.getElementById('name-info').innerHTML = 'A space with this name already exists!';
                       }
                       else
                       {
                          document.getElementById('name-info').innerHTML = '';
                       },
              error: function(type, data, evt){ alert('An error occurred!'); },
             });

As mentioned above dojo provides a huge amount of support for manipulating the page which can be utilised in the callback function, however, no server side support is provided, for this review Mabon has been used for the server side.

Mabon is a small project that was written as a result of the book 'Pro JSF and Ajax', it provides access to JSF managed beans using a mabon:<bean-name>.<method-name> syntax. It also provides a simpler API for calling the dojo bind method but that wasn't used in the review.

As a security measure the mabon servlet expects a timestamp to be present on the URL, this is generated using a custom JSF view handler. This means that the JavaScript on the page must be generated by a JSF component, thus adding a requirement to build a custom JSF component for each and every Ajax use in the web client. For the review the timestamp was added manually.


prototype, script.aculo.us and rico


script.aculo.us and rico both build upon the prototype JavaScript library which itself provides various utility methods and of course an AJAX helper. script.aculo.us and rico simply add more functionality on top i.e. drag and drop, visual effects etc. Rather than review all three only prototype was chosen as using the AJAX helper will be the same via script.aculo.us and rico.

Again, these are client only libraries so Mabon was used to hook up the server side.

In order to call server side methods with prototype the prototype.js must be included on the required page(s). The following code was used for the example:



<script type='text/javascript' src='/alfresco/scripts/prototype.js'> </script>
   
<script language='JavaScript1.2'>

function sendAjaxRequest()
{
   var pars = 'args=[' + document.getElementById('dialog:dialog-body:name').value + ']';
   var myAjax = new Ajax.Request('/alfresco/mabon/AjaxBean.spaceNameExists/<timestamp>',
         { method: 'get', parameters: pars, onComplete: checkExists });
}
  
function checkExists(originalRequest)
{
   if (originalRequest.responseText == 'true')
   {
      document.getElementById('name-info').innerHTML = 'A space with this name already exists!';
   }
   else
   {
      document.getElementById('name-info').innerHTML = '';
   }
}

Zimbra


The Zimbra AJAX toolkit has come from their collaboration suite. They have an AJAX client for their collobaration server which they have broken down into smaller 'components' and released as an AJAX toolkit. Again, the AJAX functionality is a small part of the overall package, there is also a whole widget library, an eventing framework and XML utilitiies.

However, as with most these libraries there wasn't a lot of documentation and only a handful of examples, of which none covered AJAX usage.

Upon examining the source code for the examples and finding that the following script imports were required no further review took place!



</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>

</script>

</script>
</script>
</script>

</script>
</script>
</script>
</script>

</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>

</script>
</script>
</script>
</script>

</script>

</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>

</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>
</script>

AjaxAnywhere


AjaxAnywhere is a Java based framework that literally only provides AJAX functionality i.e. there are no additional widget libraries etc.

AjaxAnywhere takes a slightly different approach than all the other toolkits in that the page is split up into 'zones'. A zone is an area of the page that needs to have dynamic behaviour. A tag is used to define and name the zone and a small amount of setup JavaScript code is added to the page to tell AjaxAnywhere which zone should be refreshed.

A servlet filter on the server intercepts the request and returns the new HTML back to the client. The AjaxAnywhere JavaScript code then refreshes the appropriate zone with the new HTML.

This approach does not lend itself very well to the example being built and in fact on the AjaxAnywhere home page it actually states as one of the disadvatages 'AxajAnywhere is not as dynamic as pure-JavaScript AJAX solutions'. All the other toolkits reviewed took less than 30 minutes to get up and running, after 2 hours with AjaxAnywhere the example was not working, so for these reasons, the review ceased at this point.


MyFaces


The MyFaces project has a few AJAX enabled components (using the prototype library on the client) but they are all in the 'sandbox' project, meaning they are completely experimental, have had no formal testing and there are no guarantees that they will even make it into the full project.

For these reasons this option was not persued any further.


Conclusion


One thing that was learnt from this experience is that the term AJAX is certainly over-used, in a lot of cases it is used to describe the whole dynamic experience whereas technically it is only the communication between the browser and server using JavaScript, the rest of the functionality should be called DHTML not AJAX!

All the client only libraries i.e. dojo, prototype, script.aculo.us and rico by definition do not supply a mechanism to return the data on the server side. Mabon was used in the tests which worked OK, however, there are 2 major disadvantages with Mabon. Firstly, the client is free to call any method on any managed bean configured on the server (provided the 'timestamp' key is known). Secondly, the 'timestamp' key must be generated via a custom JSF view handler meaning that a custom AJAX oriented JSF component has to be implemented for any AJAX feature required.

DWR, being Java based, obviously integrated very nicely with Alfresco and was by far the easiest to use, although that's to be expected as all the other toolkits have to cater for any backend URL/process! Furthermore, the beans and methods exposed to the outside world have to be configured thus providing more security than Mabon.

dojo, however, can not be ignored, it's author, Alex Russell, is one of the AJAX luminaries, examining the [well written] code shows a lot of cross-browser testing has been done, most AJAX sites and tools support dojo and the feature rich library is nothing but impressive.

The conclusion at this point is that DWR will be used for the pure AJAX requirements (the communication between browser and server) whilst dojo will be used, where appropriate, for providing the rich, dynamic user experience.

A further in-depth example will now be implemented using the chosen technologies to prove the correct choices have been made and that there is support for adding the more complex interactions with the full JSF lifecycle as mentioned in the 'AJAX and JSF' section.

Attachments

    Outcomes