myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rudy De Busscher <rdebussc...@gmail.com>
Subject Re: [VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled
Date Mon, 04 Jul 2011 07:58:56 GMT
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 <brunoaranda@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.petracek@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.korherr@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 <lu4242@gmail.com>:
>>>  > Hi Martin
>>> >
>>> > 2011/7/1 Martin Marinschek <mmarinschek@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 <lu4242@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 <lu4242@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

Mime
View raw message