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.
> 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).
Ciao Frank