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.
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
>
>
>