I can agree with jacob that "Suffix mapping is bad for resource-requests " but the choosen option shouldn't block developers from using suffix mapping for pages.
As far as I can understand the discussion -> +1 for option 2 (option 3 if we want to have an advanced config version) Regards Rudy On 3 July 2011 02:33, Bruno Aranda <brunoara...@gmail.com> wrote: > +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 >>> >> >> > -- Rudy De Busscher http://www.c4j.be
