Hi, As Dan explained at the moment Wicket provides just the logic for client side caching. And this is enough for _static_ resources. The case with Less/SASS/Stylus and similar resources is a bit more complicated because they are not static, unless you compile them at the client side. Wicket uses the last modification time of the resource to decide whether to stream it back to the client. If the resource is not modified then response with code 304 (Not Modified) is returned, _without_ body.
For dynamically created resources this is not enough. The CSS content should be generated once, for the first client, and then cached for all following clients. Response with code 304 should be returned for clients which have already received the compiled CSS content and the modification time of the .less file is still the same. The more complex logic should be in LessResourceStream#getModificationTime() - it may contain @import's and it should return the modification time of the import with the most recent update. CachingResourceStreamLocator is about caching the location of the resource, i.e. the location of the resource with the most specific attributes - locale, variation and style. Wicket will still read the input stream of the resource if the response is with code 200. CachingResourceStreamLocator just saves the time of checking all combinations of scope/name/locale/variation/style every time. I'll work to improve Wicket Bootstrap Less module with this. And probably ConcatBundleResource will need similar optimizations. On Tue, Mar 26, 2013 at 10:36 AM, Michael Haitz <[email protected]>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 <[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] > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com <http://jweekend.com/>
