Major Description
Even though we have getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl() this still is far from perfect. It will add a query parameter to resource filenames so caches should invalidate when the parameter changes. However if caching is very aggressive altering the query param might not be enough. Then there will be stale resources left in the cache of the browser or some intermediate proxy. Users will complain and you have to tell them to press F5, clear the cache, or whatever 
So I decided to implement support for adding the timestamp of the resource as part of the filename.
When you have a resource link like
<link rel="stylesheet" type="text/css" href="wicket/resource/my.great.app.HomePage/css/style.css"/>
a timestamp (the last modified timestamp of the file) will be injected into the base name of the file
<link rel="stylesheet" type="text/css" href="wicket/resource/my.great.app.HomePage/css/style-ts1282376261000.css"/>
the format is
[path-component]* / [base-filename] "-ts" [timestamp-in-milliseconds] (.extension)
The prefix "-ts" (TS = timestamp) is to avoid naming conflicts with filenames that already got with a numeric part before the extension.
Locales, style and variations are taken into consideration (e.g. style.css, style_de.css, style_en.css)
When running your test cases the MockApplication which WicketTester provides in the default case has timestamps disabled so you can check you rendered markup against some predictable url.
You can control and check timestamp behavior with
getResourceSettings().setUseTimestampOnResources()
and
getResourceSettings().getUseTimestampOnResources()
Default behavior is 'enabled'
You are now able to configure your resource caching for a very large lifetime (say 'infinite' 
and get the best possible network performance and utilization of proxies.
Attachments
Attachments
1.
|
remove obsoleted way of achieving this |
|
Resolved | Peter Ertl |