Hi
2012/11/12 Frank Caputo <frank_at_frankcaputo.de>:
> Hi Ed,
>
> Am 09.11.2012 um 23:11 schrieb Edward Burns <edward.burns_at_oracle.com>:
>
>> SECTION: Packaging Resource Library Contracts
>>
>> We must specify how the resourceLibraryContract is packaged. In JSF
>> 2.0, we introduced a special directory in the webapp root, resources,
>> and classpath area, META-INF/resources, for holding resources. I
>> suggest we introduce a new directory in the webapp root, contracts, and
>> classpath area, META-INF/contracts, and say that anything in there is
>> taken to be a resource library contract. This directory is called
>> CONTRACT_ROOT for discussion.
>>
>> If people are worried about JSF taking ownership of that name, we can
>> introduce a context-param that lets the name be modified. I'm not
>> worried about that, though.
>>
>> CONDITIONALLY_RESOLVED: Any directory within contracts in the webapp
>> root or within META-INF/contracts on the classpath is taken to be a
>> resource library contract.
>
> Where do I put resources belonging to the contract? Under META-INF/contracts/foo/resources or META-INF/resources/contracts/foo?
>
>> SECTION: Encoding Resource Library Contracts
>>
>> When encoding resources from a resource library contract so they can be
>> served during resource requests, there is no need for the system to be
>> aware of the fact that the resource is from a resource library contract.
>> The existing Resource.getRequestPath() is sufficient.
>
> So getRequestPath() will include the contract prefix?
>
>> ACTION: Will this assertion hold true if the contract itself has
>> components that have @ResourceDependencies on resources inside and
>> outside of the library? I think it will, but I need some oversight.
>>
>> SECTION: Decoding Resource Library Contracts
>>
>> As with encoding, there is nothing special to be done with decoding
>> resources during a resource request.
>>
>> SECTION: Changes to ResourceHandler.createViewResource()
>>
>> This method, new in 2.2, is the one way that Facelet resources are
>> loaded. Modify the spec to include asking the current UIViewRoot for
>> its resourceLibraryContracts property. For each entry in the path,
>> interpret that entry as the name of a contract and look for that
>> resource in the contract, if found return it. If no match is found with
>> any of the contracts, find the resource without a contract.
>>
>> ACTION: Can someone please verify that this is the only change I need to
>> make to ResourceHandler? In other words, none of the createResource()
>> methods need to be changed, only createViewResource().
>
> If we only want to do it for facelets, we would be done. But I thought this feature is about replacing any resource. If so we must also touch the other createResource* methods.
>
>> SECTION: changes to the FaceletCache
>>
>> Frank tried to explain this to me in a hangout we had, but I still
>> struggle to understand how to articulate the change that must be made
>> with respect to the FaceletCache. I think the resolution we reached was
>> that we would have to have a FaceletCache instance for each contrac.
>> Frank I need your help on this part for sure.
>
> The problem is that the facelets compiler puts the facelet (e.g. home.xhtml) and the template together. So we must ensure that we get 2 instances for 2 different contracts for the facelet. I solved this problem with a FaceletFactory for each prefix (contract). I'm not sure, if a FaceletCache instance for each contract is sufficient. We should asap start prototyping this to be sure.
>
Now I get it. In theory, FaceletCache uses an URL to identify in a
unique way a facelet,
but this URL in practice is the one related to the physical resource
to be served. So,
it does not matter if there are two different contracts with the same
facelet name, internally
the resources are located in different places and the URL stored in
FaceletCache will be
always different.
But there is another problem already mentioned related to how facelet
resources are
resolved, that needs to be fixed. In few words, if a template is is
/dirA/a.xhtml and
there is a entry like this:
<ui:decorate template="b.xhtml"/>
the related resource should be in /dirA/b.xhtml . Right now, facelets
try to derive the path
using the url of the facelet that has the reference. Instead, we
should provide a way to resolve
those scenarios in a clean way. That's the reason why we need
createViewResource(). Once
facelet has derived the alternate view resource location, it should
call createViewResource()
to get the Resource instance and get the right URL to use in FaceletCache.
In that order of ideas, we only need one FaceletCache (with the fix
over composite components).
>> SECTION: changes to the ui: facelet tags
>>
>> <ui:composition> and <ui:decorate> will have an additional attribute,
>> contract. If present, that name is taken to indicate that the named
>> template must be used from the named resource library contract. If such
>> a template is not found, it is an error, even if there is such a
>> template available outside of contract.
>
> If the contract were just a prefix for the resources, we could simply reference the template absolutely (including the prefix).
>
but if that so, there is no definition of the contract, which means
the reusability will be limited.
I'm not saying that we cannot do that, but in this case, I think it is
clear this concept helps to
keep things in order from start.
regards
Leonardo
> Ciao Frank
>
>