Java Doc for PortletAppAddResource.java in  » Workflow-Engines » wfmopen-2.1.1 » de » danet » an » util » jsf » Java Source Code / Java DocumentationJava Source Code and Java Documentation

Caching in browsers normally works by having files served to them include last-modified and expiry-time http headers.

Use this method to have full control about building the reference url to identify the resource and to customize how the resource is written to the response. In most cases, however, one of the convenience methods on this class can be used without requiring a custom ResourceHandler to be provided.

If the script has already been referenced, it's added only once.

Note that this method queues the javascript for insertion, and that the script is inserted into the buffered response by the ExtensionsFilter after the page is complete.

The resource is expected to be in the classpath, at the same location as the specified component + "/resource".

Example: when customComponent is class example.Widget, and resourceName is script.js, the resource will be retrieved from "example/Widget/resource/script.js" in the classpath.

Example: when customComponent is class example.Widget, and resourceName is script.js, the resource will be retrieved from "example/Widget/resource/script.js" in the classpath.

Caching in browsers normally works by having files served to them include last-modified and expiry-time http headers. Until the expiry time is reached, a browser will silently use its cached version. After the expiry time, it will send a "get if modified since {time}" message, where {time} is the last-modified header from the version it has cached.

Unfortunately this scheme only works well for resources represented as plain files on disk, where the webserver can easily and efficiently see the last-modified time of the resource file. When that query has to be processed by a servlet that doesn't scale well, even when it is possible to determine the resource's last-modified date from servlet code.

Fortunately, for the AddResource class a static resource is only ever accessed because a URL was embedded by this class in a dynamic page. This makes it possible to implement caching by instead marking every resource served with a very long expiry time, but forcing the URL that points to the resource to change whenever the old cached version becomes invalid; the browser effectively thinks it is fetching a different resource that it hasn't seen before. This is implemented by embedding a "cache key" in the generated URL.

Rather than using the actual modification date of a resource as the cache key, we simply use the webapp deployment time. This means that all data cached by browsers will become invalid after a webapp deploy (all the urls to the resources change). It also means that changes that occur to a resource without a webapp redeploy will not be seen by browsers.