CachingResourceStreamLocator only caches the location of files so that after the first lookup Wicket doesn't have to find out the correct locale, style, and variant for each consecutive request. It doesn't help with resources for which the content is expensive to generate. Like my LessCssResource, but also e.g. wickets ConcatBundleResource, or e.g. resources for server-side thumbnail creation.
I had a quick look at your wicket less implementation yesterday. Mine is a bit different (as far as I can tell from a quick glance at the source): * I only support/use Less4J * I use the @import features of Less4J, you seem to have added your own way of bundling multiple less files into one * I added my own implementation of LessSource that allows @import lookups for classpath, and filesystem (also absolute paths), and use the style/variant in @import lookups in the same way wicket does for resource lookups. * I don't extends CssResourceReference, which also mitigates (I think) the need for a ResourceStreamLocator I would probably have tried your implementation first if it did support a flexible enough @import for my needs Cheers, Gerrit On Tue, Mar 26, 2013, at 9:36, Michael Haitz wrote: > 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 > <pointbreak+wicketst...@ml1.net>: > > > 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: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
