Wicket has a CachingResourceStreamLocator that caches the resource streams.
here's my wicket less implementation, could be helpful too: https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/master/bootstrap-less Am 26.03.2013 um 01:01 schrieb Pointbreak <[email protected]>: > I have implemented a LessCssResource (it generates a CSS resource from > Less source files) + LessCssResourceReference. Since computing the CSS > is expensive, I would like to cache the generated CSS on the server, > once generated. It is unclear to me whether Wicket has mechanisms to do > this. I expected that IStaticCacheableResource would also provide the > means to do server side caching (in addition to setting the correct > headers and decorating the url for client-side caching). But this > doesn't seem to be the case. > > When I look at what happens when doing a second page request/refresh > after all browser caches are cleared, it seems that for IResource's that > implement IStaticCacheableResource (including my LessCssResource, but > also e.g. ConcatBundleResource from wicket core): > > * Resource.newResourceResponse is called (which obviously results in a > recompute of the entire response) > * Resource.getCacheableResourceStream is called (which also does a > recompute of the entire response) > * All implementations of these methods in wicket core resources are > designed so that both calls do a full recompute of the actual response > (which duplicates the effort for every page that uses a resource) > * The Resource itself is recreated for every request (I could cache it > in e.g. LessCssResourceReference, but nothing in wicket core abuses > ResourceReferences for server side caching of Resources, so I'd like to > know if there is a better approach). > > I have looked at Wickets own implementations of Resources that would > benefit from server side caching and happen to implement > IStaticCachableResource (e.g. ConcatBundleResource) and they seem to > have the same behaviour: no server-side caching, and for each request > the resource is actually computed multiple times: once for the actual > response, once for computing the cache-key to decorate the url. > > Hence I would like to know: > > * Should the duplicate expensive compute of various Wicket core > IStaticCacheableResource implementations not be fixed? > * Does Wicket provide any mechanism for server side caching of IResource > implementations? > > Thanks > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
