i agree with martin and jakob. regards, gerhard
http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/2 Jakob Korherr <[email protected]> > Hi, > > I totally agree with Martin on the preferred options and the filter > question. > > IMO there should not be any filter. Furthermore I really don't > understand why you want suffix mapping to work so badly, Leonardo. > Suffix mapping is bad for resource-requests (maybe even an epic fail), > because a css file is accessed via e.g. style.css.jsf. If the > mime-type is stripped or ignored or whatever, the browser (note there > are pretty bad browsers out there) might think this is a *.jsf file.. > And there are some more reasons, that I can explain on request to > everyone interested. > > Regards, > Jakob > > 2011/7/1 Leonardo Uribe <[email protected]>: > > Hi Martin > > > > 2011/7/1 Martin Marinschek <[email protected]>: > >> Hi Leo, > >> > >> how is 4 better than 2? > >> > > > > I was thinking on a scenario where some user want some other feature > > in myfaces-commons-resourcehandler like gzip compression, i18n locale > > appended to request path, library relocation of provide a custom > > request path pointing to a Content Delivery Network or just a > > directory inside the web application, and he/she is not interested in > > solution to the issue presented before. > > > > In such case, suffix mapping alone should work. Note 2 requires a > > prefixed mapping (note the assumption that /faces), but 4 does not > > enforce that, so it will work on both prefix and suffix mapping, but > > if you want a solution for the previous problem you just add the > > filter and problem solved. A filter is a simple solution to implement, > > and it will work without problem in any scenario. Note in this case > > the filter will be used only when suffix mapping is used. > > > > best regards, > > > > Leonardo Uribe > > > >> 2 is my preferred option, 3 if someone has the time to invest in this. > >> I don't see the additional value of 4. > >> > >> best regards, > >> > >> Martin > >> > >> On 6/30/11, Leonardo Uribe <[email protected]> wrote: > >>> +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 > >>>> > >>> > >> > >> > >> -- > >> > >> http://www.irian.at > >> > >> Your JSF powerhouse - > >> JSF Consulting, Development and > >> Courses in English and German > >> > >> Professional Support for Apache MyFaces > >> > > > > > > -- > Jakob Korherr > > blog: http://www.jakobk.com > twitter: http://twitter.com/jakobkorherr > work: http://www.irian.at >
