This document covers the following topics:
Ajax pages are interactive pages: the interactivity is internally implemented by the usage of JavaScript inside the pages. As a consequence, JavaScript has to be enabled.
When working with Ajax pages as a client front-end, make sure to set up the browser caching in such a way that it does not reload a page every time it is accessed by the browser. The reason for this is, that Ajax HTML pages remain stable in the browser. They do not contain any application data and are more comparable to small programs. The actual application data is filled into the pages dynamically at runtime. Also other files like JavaScript files are stable for each Natural Ajax version. If the browser is not allowed to cache them, the JavaScript files will be reloaded with each access of an Ajax HTML page.
The following sections contain recommendations on how to optimize browser caching:
The Natural Ajax JavaScript framework only loads a few JavaScript files. In previous versions of Natural for Ajax, for different controls single JavaScript files were loaded. Especially with slow connection lines, the number of files influences the loading time of an Ajax page.
For the Natural JavaScript files it is important to have the correct version of the JavaScript files in the cache of the browser. The JavaScript files usually change with different Natural for Ajax versions. It is important to run the pages exactly with the JavaScript file version for which it was generated. In previous versions of Natural for Ajax the only solutions were:
Letting the browser cache the files and then make sure that the browser cache is cleared when the Natural for Ajax version is upgraded.
Instructing the browser to always ask the server if the JavaScript file has changed before using the cached file – by setting a corresponding HTTP header in the server or the web application.
Both solutions were not optimal. The first solution required the end-users to always make sure that their cache is cleared. The second solution does not allow for optimal performance because at least a corresponding server request for the last modified date of the file had to be done.
Instead of the previous approach, Natural for Ajax uses versioned JavaScript for the JavaScript of the frequently used controls. These files now have the build version of the cisversion.xml.
ciscentralCIS_Vvrs_YYYYMMDD_HHMM_NJX.js
cisbasicCIS_Vvrs_YYYYMMDD_HHMM_NJX.js
cisadvancedCIS_Vvrs_YYYYMMDD_HHMM_NJX.js
Where vrs is the Natural for Ajax version used (e.g. 841) and YYYYMMDD and HHMM represent the date and timestamp.
It is not required to add corresponding HTTP headers to check for newer versions of ciscentral*.js, cisbasic*.js and cisadvance*.js. Every Ajax page will request exactly the JavaScript file for which it is generated. Browser and server can be configured so that these JavaScript files are cached and always accessed from the cache without any additional request to the server.
The Ajax HTML files and styles for an Ajax page are generated files from corresponding source files (*.xml, *.info). During development you may want to reload them whenever the sources are modified, which can be every few seconds. In a production environment, you usually want to reload them whenever a new version of your web application is released in your production environment.
In a development environment we recommend to set the HTTP header to:
Cache-Control: max-age=0, must-revalidate
Alternatively, you can opt for not allowing any caching at all:
Cache-Control: no-cache
In a production environment we recommend to set an HTTP header such that the client only checks the age of these files every hour:
Cache-Control: max-age=3600
This results in all clients being forced to load the new version with a maximum delay of an hour after upgrading your production environment. You can of course still force reload earlier by clearing the browser cache manually for test purposes.
In contrast to the Ajax HTML files and styles, images are not generated and usually do not change so frequently. You might think about allowing an age higher than that granted for the generated files but in most applications this does not have advantages. The recommendation is to use the same settings as for the generated files described above.
The HTTP headers recommended above can be set at different places. They can be set in
the configuration files of web applications and web application servers. They can also
be set in the web.xml file and then apply exactly to this web
application. The Natural Ajax framework contains a ready to use HttpHeader
filter which you can easily configure in your web.xml file. Search
for HttpHeader in the web.xml file and you should find
commented configuration tags, which you can use.
<filter>
<filter-name>HttpHeader</filter-name>
<filter-class>com.softwareag.cis.server.filter.HttpHeaderFilter</filter-class>
<init-param>
<param-name>Cache-Control</param-name>
<param-value>max-age=3600</param-value>
</init-param>
</filter>
...
<filter-mapping>
<filter-name>HttpHeader</filter-name>
<url-pattern>*.gif</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>HttpHeader</filter-name>
<url-pattern>*.jpg</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>HttpHeader</filter-name>
<url-pattern>*.html</url-pattern>
</filter-mapping>
...
Internet Explorer supports to switch off caching via settings in the browser itself. You need to make sure that the browser is configured so that it allows caching at all.
In Internet Explorer, you set up caching via . On the General tab of the resulting dialog box, choose the button in the Temporary Internet files group box. The following dialog box appears:
Either select the option Automatically or Every time you start Internet Explorer.
The default browser setting in most browsers is to block pop-ups.
By default, Natural Ajax pop-ups are opened as page pop-ups, instead of browser pop-ups.
See the attribute usepagepopups in the cisconfig.xml.
Only some controls like the DATEINPUT controls use browser pop-ups. There is
a newer DATEINPUT2 control, which does not use browser pop-ups. If you use
controls requiring browser pop-ups in your application, you need to switch off the
browser’s pop-up blocker. You can find the corresponding setting in the
Security tab of the browser options.