myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Korherr <jakob.korh...@gmail.com>
Subject Re: [VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled
Date Sat, 02 Jul 2011 21:06:18 GMT
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

Mime
View raw message