public interface Caching
<script src='/foo/bar.js?version=13'></script>A URL for the same resource including a path component (in this case
might look like this:
<script src='/v13/foo/bar.js'></script>The server would of course need to resolve this URL to the appropriate resource.
Note: Smart GWT dynamically assembles URLs to retrieve images and CSS from the
current skin. It's not possible to pervasively apply
query parameter to these dynamically assembled URLs, so if you want to use
versioned URLs to ensure that new versions of skin resources are requested when
the Smart GWT version changes, versioned URLs must be applied with a path component.
For developers using the
Smart GWT server, the
loadISC JSP tag automatically generates version-specific URLs for loading
Smart GWT resources, and can be configured to use either URL-parameters or path segments.
The Smart GWT server can automatically resolve
URLs including Smart GWT version path segments to the approprirate target resources via
the FileDownload servlet or the dedicated VersionedURLFilter.
Server_properties configuration can be used to configure
behavior for Smart GWT JSP tags, and to enable or disable stripping these URL segments when
Developers do not need to use the Smart GWT server to apply or resolve version-specific URLs of course.
It's trivial to apply a versioned URL to the
<script src=...> tags
used to load Smart GWT framework modules and the
load_skin.js file for your skin.
If you included a version-specific path segment in the script tag to retrieve
skin directory will automatically pick
this up, meaning all requests
for dynamically loaded skin media will also include the path segment.
Page.setSkinDir('/version/13/isomorphic/skins/SmartGWT/');You can then either deploy the resources under the versioned directory above or use a URL rewriting engine such as mod_rewrite for Apache to map all such versions into a single deploy directory.
Generally the version number in a versioned URL wouldn't be hard-coded into a dynamic page, but would instead pick up the value of a variable, such that you can simply bump up the value in one configuration file and have all versioned URLs change dynamically.
To actually tell the browser to cache files for a longer length of time than the browser session, you need to set the HTTP 'Expires' header. If you're not using the Smart GWT Java back-end there are several caching solutions available, depending on your server of choice. Microsoft's IIS has built-in caching capability, please check the reference manual for details. If you're using Apache, you can use mod_expires. Some servlet containers also natively support the setting of caching headers.
The Smart GWT Java back-end supports setting caching headers via the FileDownload service on a per-mimetype basis. To use it, first register the FileDownload servlet in your web.xml as follows:
Next, map any resource that you want to serve with caching headers to the FileDownload servlet in your web.xml. Typically, you'll want to serve the Smart GWT modules and all skin images with caching headers. You can do so by adding the following servlet-mapping directives to your web.xml:
<servlet-mapping> <servlet-name>FileDownload</servlet-name> <url-pattern>/isomorphic/system/modules/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>FileDownload</servlet-name> <url-pattern>/isomorphic/skins/*</url-pattern> </servlet-mapping>