+1 for 3. Option 4. doesn't cause any conflict, so we can just keep that code as is.
2011/6/30 Leonardo Uribe <[email protected]>: > Hi > > To reference images inside a css file in JSF 2.0, users have to change > its code from this: > > .someclass > { > ... > background-image:url('myimage.gif'); > ... > } > > to this: > > .someclass > { > ... > background-image:url(#{resource['mylib:myimage.gif']}); > ... > } > > This means a lot of changes, including override css files and copy > images to other locations. > > Some months ago, a new module was added in MyFaces commons, with the > objective of handle that problem in a gracefully way (just don't > change anything on the css file and make JSF load the images). But > there are different points of view about how to handle it on the > implementation of that module. > > Things works well when prefix mapping is used for FacesServlet. But > with suffix mapping, by default all resources have an additional > suffix added on its request path. So, the resource url looks something > like this: > > http://[server][port]/[webapp]/javax.faces.resource/mylib/image.gif.jsf > > breaking the css file. > > The intention is allow suffix mapping for jsf files, but prefix > mapping for resource links. There are the following alternatives: > > 1. Enforce prefix mapping for jsf applications using this module and > do not support suffix mapping at all. > > 2. Add a prefix mapping entry for FacesServlet and create a web config > init param to indicate that mapping will be used to handle resources. > If such param is no present, assume "/faces" as prefix mapping used. > > 3. Add a prefix mapping entry for FacesServlet and detect it > automatically, parsing web.xml file and in servlet 3.0 use > ServletRegistration. A web config init param anyway should be provided > for handle portlets case. > > 4. Use a special filter and detect if was setup automatically, looking > on application map if the filter was set or not and a web config init > param to know the mapping used, without parse xml files or servlet 3.0 > specific code. > > Please vote about which one you think is the best alternative, and > should be done in that module. > > Please note: This vote is "majority approval" over the choice selected > (see [1]). > > Thanks, > Leonardo Uribe > > [1] http://www.apache.org/foundation/voting.html#ReleaseVotes >
