+1 for 3 Between 2 and 4, I still prefer a filter. For me an init param to deal with such a specific case is more obscure than a filter, but it may be my intuition,
Cheers, Bruno On 3 July 2011 00:20, Gerhard Petracek <gerhard.petra...@gmail.com> wrote: > 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 <jakob.korh...@gmail.com> > >> 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 <lu4...@gmail.com>: >> > Hi Martin >> > >> > 2011/7/1 Martin Marinschek <mmarinsc...@apache.org>: >> >> 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 <lu4...@gmail.com> 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 <lu4...@gmail.com>: >> >>>> 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 >> > >
