+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
>

Reply via email to