Inline...
On Wed, Mar 27, 2013 at 10:41 PM, Bertrand Guay-Paquet <
ber...@step.polymtl.ca> wrote:
> First, when you say you serve files out of webapp folder, do you mean
>> you're not using any ResourceReference?
>>
> To answer your question, here's what I use to access my webapp resources:
> -ContextImage which uses context-relative urls
> -RelativePathPrefixHandler which handles hrefs in the markup and makes
> them context-relative
> -UrlResourceReference with, again, context-relative urls
Since your stated goal is better control of caching and versioning, with a
mind to eventual use of CDN, I think this approach is limiting. Changing
images and fonts usually involves files with new names, so there is no
caching problem here. But you probably don't want to manually rename your
CSS every time you tweak a style rule. If you make these resources, then
Wicket's default caching strategy
(FilenameWithVersionResourceCachingStrategy + MessageDigestResourceVersion)
will add an MD5 of the content to the filename, forcing browsers to request
the new CSS. It is our experience that modification timestamps (which is
all your web container can use) are not sufficient. The comment
on QueryStringWithVersionResourceCachingStrategy indicates that we're not
the only ones to notice this-- even versioned query parameters may not be
enough!
What does LESS mean in the first line of the paragraph above? Do you do
> anything special to "flatten" the css files?
>
What Martin said. Our CSS files are compiled at build time
with lesscss-maven-plugin.
> So, to not "worry about relative-path includes from CSS", you must make
> the images non-versioned, correct? Do you do this using ResourceReferences
> and IStaticCacheableResource#**isCachingEnabled() ?
>
Partially correct. Images are not versioned in the sense that their
filenames have no version in them. But when I talk about relative-path
includes, I don't mean any kind of ResourceReference. I simply mean CSS
style rules like:
.icon-white { background-image: url('../images/glyphicons-halflings.png'); }
The image always gets loaded from the same server as the CSS. So if we
decorate resource URLs to point at a CDN, the CSS file gets loaded from CDN
and so do any fonts and images to which it refers.
I haven't had a chance to do this yet, but I'm looking forward to trying
the RemoteHostResourceMount in WicketStuff described here:
http://techblog.molindo.at/2011/03/serving-wicket-resources-from-cdn.html
Quite simple if your resources are served through ResourceReferences, but I
think not so simple with ContextImage and friends.
If you use ResourceRefenrecs, does that mean that all your assets (css, js,
> images,...) are stored along with the java class files (i.e.
> src/main/resources in Maven terms) ?
>
Yes, because we use PackageResourceReference, all assets are on the
classpath.
To be honest, most assets are not finely split into component-specific Java
packages as prevailing wisdom would suggest. Our designers prefer having
their assets in big buckets. So we created a separate Maven artifact with a
directory structure they're happy with (not /src/main/resources, sadly).
Previously we used maven-assembly-plugin to assemble this into a directory
that got served directly from HTTPD (not Wicket) from a top-level /assets
folder. But to solve the CSS caching problems I described previously, we
changed this assets artifact into a JAR deployed with the Wicket app. The
JAR has a class with simple, static factory methods for script, css, and
image HeaderItems.
Obviously if your goal is reusable, self-contained components this approach
is not a good one. But I suppose serving assets from webapp folder already
breaks encapsulation.
> Thanks again!
My pleasure.
Dan
