Hi Leonardo,
Am 29.08.2012 um 05:52 schrieb Leonardo Uribe:
> Hi Frank
>
> 2012/8/28 Frank Caputo <frank_at_frankcaputo.de>:
>> Hi Leonardo,
>>
>> Am 25.08.2012 um 21:42 schrieb Leonardo Uribe:
>>
>>> Hi
>>>
>>> FC >> Library and resource name result in a resource identifier.
>>> FC >> So if we call the new method
>>> FC >> ResourceHandler.getResourcePrefix(FacesContext),
>>> FC >> we can simply prefix all resource identifiers and have it.
>>>
>>> It is not so simple, because one of the requeriments for the solution
>>> is the generated resource url should include all necessary infomation
>>> to locate the resource. Adding a prefix to a resource name means
>>> when the resource is handled we need to extract it from the
>>> resource name, which could be hard to do.
>>
>> No. The faces context must have all information to determine the prefix (maybe the host-header or the session). The generated path should be the same for prefixed and non prefixed resources (as Ed stated earlier: the skin information should never go to the client).
>>
>
> It doesn't sound good, because that means the resource cannot be
> cached, and it is not possible to set cache headers. I don't think it
> is a good idea to reuse the generated path.
If you use the hostname to choose the resource prefix, caching will work as is. Anyway, JSF allows resources to change even in production mode, so caching is per se a problem.
Ciao Frank
>
> With the hack using the libraryName, since the generated path contains
> the libraryName once resolved, it solve the problem in a clean way. No
> skin info is sent to the client, resources can be cached in the client
> side and the entries on the server side, and it is possible to create
> a ResourceHandler implementation that generate unique urls.
>
> regards,
>
> Leonardo
>
>> Ciao Frank
>>
>>>
>>> In theory you can ignore it, but "... I have a bad feeling about this...",
>>> because in theory a Resource instance built from a resource url should
>>> be identical to the one that generates it.
>>>
>>> FC >> Having the getDefaultLibraryNames solution, we don't even
>>> FC >> need {theme}, because this is handled transparently.
>>> FC >> You will always use <ui:composition template="/shoppingtemplate.xhtml">
>>>
>>> Yes, the advantage of delegate to ResourceHandler is that we can
>>> override how to find a resource without change the template code.
>>>
>>> FC >> We are nearly. I think, the caching problem might be solved,
>>> FC >> if we always use the prefix in the cache key. This way we get
>>> FC >> two instances cached, if we fall back to no prefix, even if we
>>> FC >> only need one.
>>>
>>> Any cache must contains all necessary info to locate the resource instance.
>>> In myfaces there is a class called
>>> org.apache.myfaces.shared.resource.ResourceHandlerCache with a method:
>>>
>>> public boolean containsResource(String resourceName, String libraryName,
>>> String contentType,
>>> String localePrefix)
>>>
>>> which covers all possible combinations. Include a prefix means update the cache
>>> to include that concept, but note in this case it is expected to extract the
>>> prefix from the resource url to get the right Resource instance.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2012/8/24 Frank Caputo <frank_at_frankcaputo.de>:
>>>> Hi Leonardo,
>>>>
>>>> Am 13.08.2012 um 03:52 schrieb Leonardo Uribe:
>>>>
>>>>>> I think tying it to the library name is a good idea. Maybe we can have something like ResourceHandler.getDefaultLibraryName(FacesContext), which is simply a prefix for all resources requested in the given FacesContext. E.g:
>>>>>>
>>>>>> ResourceHandler.getDefaultLibraryName(FacesContext) returns "mobile"
>>>>>> ResourceHandler.createResource("main.css", "css") becomes ResourceHandler.createResource("main.css", "mobile/css")
>>>>>> If ResourceHandler.createResource("main.css", "mobile/css") returns null, use ResourceHandler.createResource("main.css", "css")
>>>>>>
>>>>>
>>>>> It is an option, but it has its advantages:
>>>>>
>>>>> - It is only required to extend the concept of libraryName.
>>>>> - No need to update request url spec.
>>>>>
>>>>> and disadvantages.
>>>>>
>>>>> - If skinning/templating is built on top of libraryName, no changes in
>>>>> request url are required, but all limitations of libraryName applies,
>>>>> like do not allow '/' in libraryName, so the example proposed
>>>>> replacing libraryName with "mobile/css" is invalid according to
>>>>> current spec. See: https://issues.apache.org/jira/browse/MYFACES-3454
>>>>> for details.
>>>>
>>>> Library and resource name result in a resource identifier. So if we call the new method ResourceHandler.getResourcePrefix(FacesContext), we can simply prefix all resource identifiers and have it.
>>>>
>>>> Ciao Frank
>>>>
>>>>
>>>>
>>>