Thanks! Just FYI: with Less4j it's actually quite easy to get the modification time of the most recently updated import, since it creates a list of all used imports on the top level LessSource
On Tue, Mar 26, 2013, at 10:13, Martin Grigorov wrote: > 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/> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
