Cool! I took a slightly different route, as explained in a previous mail. I may try to find some time to see if both implementations could be merged, but I'll have to check license issues first. What I built is tightly integrated with Less4J so I'm not so sure merging the two would make sense for wicket-bootstrap anyway.
I put a few comments inline below. Will try to make some time free later to have a look at the pull request. Cheers On Wed, Mar 27, 2013, at 15:50, Martin Grigorov wrote: > Hi, > > At https://github.com/l0rdn1kk0n/wicket-bootstrap/compare/cached-less you > may see the diff between master and cached-less branches. > I still have to discuss the changes with Michael Haitz but your feedback > is > welcome too! > > LessResourceReference is a specialization of CssResourceReference so it > can > be used like: > > > @Override > public void renderHead(IHeaderResponse response) { > super.renderHead(response); > > response.render(CssHeaderItem.forReference(new > LessResourceReference(HomePage.class, "demo.less"))); > } You don't need a CssResourceReference for that, any ResourceReference can be used like that. > LessPackageResource is a specialization of CssPackageResource so all that > is valid for CPR is valid for LPR too - compression, minified name, etc. Why would you want to have a minified name for your less source file? Only the output after compilation goes to the client. The compression (I guess you mean minification) can be handled by Less as well. > The real logic is in LessCacheManager that handles the server side > caching > for the generated CSS content per Less resource. > As I explained earlier: > - if a request without 'If-Modified-Since' request header is being > processed then the cache manager is being advised > - if there is no CSS content entry in the cache then the Less resource is > compiled on the fly > - if there is CSS entry then it is returned > - if there is 'If-Modified-Since' then it is used by the cache manager to > compare it against the last modification time of the root Less resource > and > all imports in it > - if the Less resource is newer then the cache manager returns either the > generated CSS or re-generates a new one if the CSS has been generated is > before the last modification of the Less file(s) Please note that LessSource.URLSource is not threadsafe, your CacheManager seems to assume that. I went the same route as you, caching LessSource, but made my own threadsafe LessSource implementation for that (and also to @imports much much more flexible). > > On Tue, Mar 26, 2013 at 11:29 AM, Pointbreak > <[email protected] > > wrote: > > > 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] > > > > > > > -- > 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]
