Hi
2012/11/9 Edward Burns <edward.burns_at_oracle.com>:
> Hello Volunteers,
>
> This email thread will resolve how and when the resourceLibraryContracts
> property is used. There are two other threads, one that resolves the
> name of the property for storing the resource library contracts, and
> when and where the value of that property is set, and another regarding
> *how* the value of the property is calculated.
>
> 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.
>
I like the idea. Use a different folder has sense, because a resource library
contract uses an "extended model" than the one for normal jsf resource
libraries, but in some parts it has a similar behavior.
But note find the available contracts can be an expensive operation. In JSF
2.0, the concept of library/resource versions was added, but because an
implementation detail about jar files (it is not possible to scan a
folder without
read the whole jar file), it was necessary to disable that concept when used
inside jar files (META-INF/resources).
Anyway, it is possible to scan for resource library contracts only at startup
time. When a resource request path is resolved, this scan should be avoided.
Probably, as an implementation detail in MyFaces it will be necessary to
provide SPI interfaces to customize this detail, as it has been done previously
in other similar cases.
> 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.
>
Ok. Note that resources inside this folder probably should be handler
in a similar
way as resources inside META-INF/resources
> 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.
>
> 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.
>
I agree with you. The important part here is define the precedence (which one
is scanned first, a library in META-INF/resources or a library in
META-INF/contracts, but at the end, since there will not be a library with the
same name in both folders, there is no need to worry about).
> 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().
>
It is possible to use @ResourceDependency annotation to load a resource
inside a resource library contract implementation? if the answer is yes, we need
to do modifications in createResource() methods (META-INF/contracts is an
alternate package type).
> 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.
>
It is possible to load/unload resource library contracts when the application
is running? If it is not, one FaceletCache per app is enough, otherwise, it is
necessary to define a "lifecycle" for facelet instances stored in the cache.
I think we have discussed before the need of solve some issues related to
FaceletCache. For example, in MyFaces there are 3 types of facelets
(Mojarra has 2):
- Normal Facelet :
- View Metadata Facelet : Calculates metadata info about a view.
- Composite Component Metadata Facelet : Calculates metadata info about
a composite component.
I strongly think FaceletCache needs to be updated to include the third type,
even if Mojarra does not use it. But that's another history.
What's important here is if the assumption that if it is possible to
add and remove
resource library contract on runtime.
> 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.
>
Yes, that's right.
regards,
Leonardo
> ACTION: Please reply by 17:00 GMT Tuesday 20121113, earlier if you can manage!
>
> Thanks,
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/