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
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 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
Fair enough. I also see that in deployment mode wicket actually caches
the decorated url of resources for the entire application lifetime, so
the Resource.getCacheableResourceStream isn't repeated each time a page
is rendered with a reference to a resource.
On Tue, Mar 26, 2013, at 2:09, Dan
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
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,
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
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
I believe Wicket's resource versioning and caching logic simply provides
advice in HTTP response headers, and decorates filenames if so configured.
Do your requests come directly to Wicket's container? We reverse proxy with
HTTPD, which is probably better at caching than a Java solution could ever
