wicketstuff-merged-resources: 2.1 and 3.0 released!
February 5th, 2010 by Stefan Fußenegger | Published in Java, Wicket, wicketstuff-merged-resources | 2 Comments
I’m happy to announce the releases of wicketstuff-merged-resources 2.1 and 3.0.
Changes from 2.0 to 2.1 (Wicket 1.3.x):
- Annotation-based Mounting of Resources
- [WMR-7] Failure to load resources if this library is provided in a parent classloader
- [WMR-9] Make it possible to define some sort of order in the way files are included in the overall file
- [WMR-10] wicketstuff-merged-resources does not compile; missing jetty plugin artifact
- and a few minor bug fixes and performance improvements: See full FishEye Activity report
(Note: [WMR-12] and [WMR-14] already went into 2.2-SNAPSHOT)
Changes for 3.0 (Wicket 1.4.x):
- Annotation-based Mounting of Resources
- [WMR-6] Compatibility to wicket 1.4
- [WMR-7] Failure to load resources if this library is provided in a parent classloader
- [WMR-9] Make it possible to define some sort of order in the way files are included in the overall file
- [WMR-10] wicketstuff-merged-resources does not compile; missing jetty plugin artifact
- [WMR-12] Allow CSS media to be specified in ResourceMount, and honored by build()
- [WMR-14] Error detection for adding CSS and JavaScript resources to ResourceMount
- and a few minor bug fixes and performance improvements: See full FishEye Activity report
Downloads:
September 9th, 2010 at 15:04 (#)
Hi Stefan,
Is it also possible to have a subset of the CSS for a page?
Suppose I have the following
Page1.java
common.css
Page1.css
Page2.java
common.css
Page2.css
Now the Page2.css and the Page1.css will be merged in all.css. Is it possible to merge all the css files for one page (or panel), but not having the css come up in other pages?
So, effectively this will happen:
Page1.java has one css in the section, merged from common.css and Page1.css
Page2.java has one css in the section, merged from common.css and Page2.css
Is that possible?
September 9th, 2010 at 17:16 (#)
No, that’s not possible. Instead, you should consider merging all three into one file or simply keep them separate.
You could also take a look on your site’s access statistics to check which page is the most important entry page. Assuming it’s Page1, you could merge Page1.css and common.css and keep Page2.css separate. If a user accesses Page2 there’s a good chance that the merged common.css is already in cache.
Unfortunately, I don’t know of a way to measure cache hit rates for resources (as you can see at http://stackoverflow.com/questions/3300891/how-to-measure-http-cache-hit-rates). Hence tuning is all about such assumptions.
Hope this helps.