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")));
}
LessPackageResource is a specialization of CssPackageResource so all that
is valid for CPR is valid for LPR too - compression, minified name, etc.
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)
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/>
