Resource handling in RF 4.2
josh68 Feb 17, 2012 3:46 PMThanks for this informative blog post (http://rik-ansikter.blogspot.com/2012/02/re-routing-jsf-resource-requests-with.html), and I'm glad resource optimization and loading are separated now. I'm also trying to get real control over resource loading using a customized version of this proposed workaround: https://community.jboss.org/wiki/WorkaroundForLOADNONEResourceLoadingStrategyInRichFaces41#comment-8974.
However, I'm pretty much all confused about what previous mapping strategies still apply and how this all is supposed to work. I'll try to break down what options (context params) I've seen discussed. Whatever here is deprecated, would be good to know. And actual scenarios, with all needed configs, would be a great help.
- Generic resource mapping enabled: "org.richfaces.resourceMapping.enabled", value "true") - seems this may now be deprecated/unnecessary, but not sure.
- Generic (dynamic resource override?) resource mapping properties file: "org.richfaces.resourceMapping.mappingFile", pointing to properties file location - suggested path of "/META-INF/richfaces/custom-mapping.properties" [or "custom-mappings.properties" - plural], but should it now point to the file "static-resource-mappings.properties"?)
- Generic (dynamic resource override?) resource mapping location: Root of where resources are located - with a suggested path of "#{facesContext.externalContext.requestContextPath}/resources/#{resourceLocation}" - the root location of your local resource libraries, like js, css, etc.
- Static resource mapping properties file: "org.richfaces.staticResourceLocation.mappingFile", pointing to properties file location - suggested path of "/META-INF/richfaces/static-resource-mappings.properties". Seems this may or may not be necessary if a file called "static-resource-mappings.properties" is anywhere in your classpath, or is it deprecated altogether?
- Static resource mapping location: "org.richfaces.staticResourceLocation", with a suggested path of maybe just "#{resourceLocation}", eg, for CDN. Is this even necessary anymore or is it deprecated? See https://community.jboss.org/message/591640#591640
It might also be helpful for me to clear up whether "static" here means a static location or static loading, or both, and whether mapping -- using any strategy -- a default, dynamically loaded resource to a static location turns it into a static resource (ie, it will be loaded regardless of what components happen to be in the page).
Finally, although mapping and optimization have now been split apart, I'm still wondering whether it will be effective in RF during deployment, when packing and compression s/b enabled. Because, for example, packed.js (which is already built in the jar) contains a full version of jquery.js, so if I'm pointing jquery.js to a CDN in my mapping file, won't the CDN script file collide with the version in packed.js in a deployment environment? Can this strategy only work if packing is disabled, or if I make a custom packed-patched.js, with jquery.js removed?
Hope any of this makes sense. Thanks.