[jira] Updated: (WICKET-3021) Add timestamp part to resource filenames for better caching
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-3021: --- Attachment: timestamp-for-resources.patch updated patch for current trunk > Add timestamp part to resource filenames for better caching > --- > > Key: WICKET-3021 > URL: https://issues.apache.org/jira/browse/WICKET-3021 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5-M1 >Reporter: Peter Ertl > Attachments: timestamp-for-resources.patch > > > 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 >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 >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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3021) Add timestamp part to resource filenames for better caching
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-3021: --- Attachment: (was: timestamp-for-resources.patch) > Add timestamp part to resource filenames for better caching > --- > > Key: WICKET-3021 > URL: https://issues.apache.org/jira/browse/WICKET-3021 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5-M1 >Reporter: Peter Ertl > > 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 >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 >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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3021) Add timestamp part to resource filenames for better caching
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-3021: --- 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 a timestamp (the last modified timestamp of the file) will be injected into the base name of the file 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. was: 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 a timestamp (the last modified timestamp of the file) will be injected into the base name of the file 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 should now be able to configure your resources caching to 'infinity' which will give you best network performance and utilization of proxies. > Add timestamp part to resource filenames for better caching > --- > > Key: WICKET-3021 > URL: https://issues.apache.org/jira/browse/WICKET-3021 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5-M1 >Reporter: Peter Ertl > Attachments: timestamp-for-resources.patch > > > 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 >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 >href="wicket/resource/my.great.app.HomePage/css/style-ts1282376261000.css"/> > the format is > [path-component]* / [base-filename] "-ts" [timestamp-in-milliseconds] > (.ex
[jira] Updated: (WICKET-3021) Add timestamp part to resource filenames for better caching
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-3021: --- 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 a timestamp (the last modified timestamp of the file) will be injected into the base name of the file 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 should now be able to configure your resources caching to 'infinity' which will give you best network performance and utilization of proxies. was: 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 a timestamp (the last modified timestamp of the file) will be injected into the base name of the url 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 should now be able to configure your resources caching to 'infinity' which will give you best network performance and utilization of proxies. > Add timestamp part to resource filenames for better caching > --- > > Key: WICKET-3021 > URL: https://issues.apache.org/jira/browse/WICKET-3021 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5-M1 >Reporter: Peter Ertl > Attachments: timestamp-for-resources.patch > > > 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 >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 >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
[jira] Updated: (WICKET-3021) Add timestamp part to resource filenames for better caching
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-3021: --- Attachment: timestamp-for-resources.patch > Add timestamp part to resource filenames for better caching > --- > > Key: WICKET-3021 > URL: https://issues.apache.org/jira/browse/WICKET-3021 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5-M1 >Reporter: Peter Ertl > Attachments: timestamp-for-resources.patch > > > 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 >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 url >href="wicket/resource/my.great.app.HomePage/css/style.css-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 should now be able to configure your resources caching to 'infinity' > which will give you best network performance and utilization of proxies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
