Refresh strategy in complex templates

In a Rich Internet Application, the user interface has to reactively change upon user interaction or after receiving data from the server. Aria Templates offers several mechanisms for refreshing the view (as explained in this article).

Full or partial refresh?

It is possible to trigger the refresh of a template by calling the $refresh method from the Template Script. If no argument is provided, the whole template will be refreshed. However, it is possible to choose which section of the template to refresh: sections can be actually considered as “refresh units”, and as such they play an important role in the template structure. Moreover, the refresh of a section can also be bound to the data model.

Choosing the correct refresh strategy is of crucial importance for performance reason, hence it is advisable to keep it in mind when designing your templates and to test different options.

An interesting use case to consider consists in the simultaneous refresh of many sections of the same template: is it really more efficient to go for a partial refresh of many sections or is there a limit after which a full refresh is more convenient? There is no general answer to this question, so it is up to you to make some performance tests.

The purpose of this article is to provide some figures on a specific use case. However, some of the conclusions are of general validity and the adopted testing strategy might be inspiring for the tests that we suggest you should do before taking a final decision on how your template is going to be refreshed.

 Use case

Consider the following template:

{Template {
  $classpath : "tests.refreshstrategy.ColorfulSquares",
  $css : ["tests.refreshstrategy.ColorfulSquaresCSS"],
  $hasScript : true

  {macro main()}
    {var squaresCount = data.squaresCount /}
    {for var i = 1; i <= squaresCount; i++}
      {section {
        id : "square_" + i,
        macro : {
          name : "printOneSquare",
          args : ["square_" + i]
  {macro printOneSquare(name)}
    <span {id name + "_elt"/} class="square ${getRandomClass()}"></span>



It displays a certain number of squares with a class that is randomly chosen amongst a list (by means of the function getRandomClass defined in the corresponding script). A section is used to wrap every square, so that it is possible to update a subset of the output squares by selectively refreshing the corresponding sections (the source code for the example is available below).

Although the example is not realistic, it will allow us to draw some conclusions on the refresh strategy. After setting a total number of squares N, we refresh n sections several times and compute the average time needed to perform the operation. By letting n vary, we obtain the red curves in the following figures.

As you can see, when n reaches a certain value, the time it takes for partial refreshes becomes greater than a full refresh interval. Results are of course different according to the browser.

We remark that reported results only refer to the javascript execution time, not to the rendering time that heavily varies across browsers.

Stop/resume of the Refresh Manager

When several refresh operations in a row have to be performed, it is always advisable to optimize them by using the api of the RefreshManager. In particular,

  • stop refresh operations before triggering refreshes (aria.templates.RefreshManager.stop()),
  • resume them once all refresh statements have been invoked (aria.templates.RefreshManager.resume()).

The RefreshManager is able to minimize the number of refreshes by avoiding multiple refreshes of the same section. It is automatically stopped and resumed inside every $refresh operation, for internal reasons. Since it can be cumbersome to resume it, it is better to stop it once and for all before multiple calls to the $refresh method, to resume it later.

The blue curves in the above figures are obtained by triggering the refresh manager. It is evident that performances are far better. It is also interesting to notice that  when n is greater than the maximum number of sections (in which case some sections are refreshed multiple times) the curve is flat, because multiple refreshes on the same sections are merged into one by the refresh manager.

Is a refresh necessary?

In our use case, we are refreshing a section just in order to get a new random class to assign to the span representing a square. Of course we could obtain the same result by retrieving the element and setting a new class for it. The following figures report the javascript execution times for performing such operation as opposed to implementing a refresh strategy.

As you can see, it is convenient to go for a class change (by assigning id’s, retrieving DomElementWrappers through the $getElementById method and using the classList utilities).



The trivial use case presented in this article has allowed us to provide some evidence that:

  • It is always better to use the stop/resume methods of the RefreshManager before performing multiple refresh operations.
  • If you have a lot of sections in a template and you want to refresh a subset of them, the choice between a partial refresh and a full refresh depends on the number of sections and also on the browser. We suggest to make some tests in older browsers in order to find the worst case.
  • Sometimes a refresh is not necessary. Old-style class change might do the job better. Of course this applies to very simple and specific situations, but it is better to remind it.

The refresh strategy that you put in place is going to severely influence the user experience, so it has to be conceived with care.

Source code

Here is a zip folder containing the files needed to run tests on the scenario introduced above. Place the refreshstrategy folder in the docs folder of your local server. The sample assumes you have the Aria Templates framework in a folder called “aria-templates” inside the docs root. Change the index.html file to adjust to your situation.

Leave a Reply

Your email address will not be published. Required fields are marked *