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).
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
>>
>>
>>
>
-
Frank Caputo
Johann-Mohr-Weg 24d
22763 Hamburg
Mobil +49 177 61 61 81 3
E-Mail info_at_frankcaputo.de