I don't think there's anything wrong with serving resources from the webapp-folder, and making the webapp container (e.g. jetty) responsible for serving them instead of Wicket. Most webapp containers will serve static resources much more efficiently than any servlet-based (including Wicket's) approach will do. It's also easier to switch to CDN, because your resources are already served as static resources. Just change to the new URL's. The container should be able to serve your static resources with proper long-time caching headers. You should make sure that the paths of these resources contain a version, so that when you update a resource to a new version, clients will see it as a new (uncached) resource. You can add the links directly in your markup, or use UrlResourceReference in your java for this approach. The result is the same.
Serving with Wicket (e.g. PackagedResourceReference) makes sense if: - You need the locale/style/variation resource lookups of PackagedResourceReference - You want Wicket to automatically detect new versions of resources (wicket changes the url to include a version number) - You want to serve resources from the classpath, instead of the webapp folder Cheers On Wed, Mar 27, 2013, at 23:24, Dan Retzlaff wrote: > Hi, Bertrand. I don't have all your answers, but I can share my > experience. > > First, when you say you serve files out of webapp folder, do you mean > you're not using any ResourceReference? Just absolute paths from markup? > I > think improving that is the first thing to do. You need to process > resource > references in Java so you can introduce versions, CDN base URLs, etc. > > The main caching problem we had was that after upgrades, some clients had > the old CSS cached and the site looked funky for them. So we went through > and made sure all CSS is served through PackageResourceReferences. > Wicket's > default versioning strategy then did its magic and that complaint > stopped. > > With respect to @import, we have many @imports in our source LESS, but by > the time it's being served, the CSS is flat. So versioning that is > enough. > It's possible but I think far less likely that this kind of caching > problem > will happen for images and fonts. Direct references to these from our > application still go through ResourceReferences just so they can be > served > from CDN, but we don't worry about relative-path includes from CSS. > > Hope that helps. > > Dan > > On Wed, Mar 27, 2013 at 2:15 PM, Bertrand Guay-Paquet < > [email protected]> wrote: > > > Hello, > > > > I'm trying to figure out the optimal way to deal with caching and out of > > date resources and can't really find which methodology to adopt. > > > > Considering that: > > a) css and js files are only accessed from web pages > > b) image files are accessed from web pages and from email clients (links > > stored for a long time) > > c) image files are referenced from css (e.g. background-image url) > > d) font files are accessed from web pages and maybe eventually from email > > clients > > e) some css files currently use "@import" statements to include other css > > files (this could be removed if needed) > > f) css, js, fonts and images currently are all located in the webapp > > folder (i.e. I wasn't able to access them with PackageResourceReference) > > g) whatever the approach, it needs to be compatible with eventual usage of > > CDN services > > > > Questions: > > 1- Which files should be versioned? > > 2- Should they be versioned using Wicket's ResourceReferences? > > 3- Are there other considerations I haven't thought about? > > 4- Which successful approaches are in use now by other Wicker users? > > > > Thanks for your insight! > > > > Regards, > > Bertrand > > > > ------------------------------**------------------------------**--------- > > To unsubscribe, e-mail: > > users-unsubscribe@wicket.**apache.org<[email protected]> > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
