Hi Ed,
Am 13.11.2012 um 03:21 schrieb Edward Burns <edward.burns_at_oracle.com>:
>>>>>> On Mon, 12 Nov 2012 20:50:55 +0100, Frank Caputo <frank_at_frankcaputo.de> said:
>
> FC> Am 09.11.2012 um 23:11 schrieb Edward Burns <edward.burns_at_oracle.com>:
>
> EB> CONDITIONALLY_RESOLVED: Any directory within contracts in the webapp
> EB> root or within META-INF/contracts on the classpath is taken to be a
> EB> resource library contract.
>
> FC> Where do I put resources belonging to the contract? Under
> FC> META-INF/contracts/foo/resources or
> FC> META-INF/resources/contracts/foo?
>
> I was thinking it would be
>
> <root>contracts/foo
>
> or
>
> META-INF/contracts/foo
>
> directly.
OK.
> EB> ACTION: Can someone please verify that this is the only change I need to
> EB> make to ResourceHandler? In other words, none of the createResource()
> EB> methods need to be changed, only createViewResource().
>
> FC> If we only want to do it for facelets, we would be done. But I
> FC> thought this feature is about replacing any resource. If so we must
> FC> also touch the other createResource* methods.
>
> Yes, we do want to do it for all kinds of resource. Frank, can you
> sketch out some text for the other createResource*() methods?
Currently both createResource(…) methods refer to "The algorithm specified in section JSF.2.6.1.4 of the spec prose document". I think we should modify this section and change deriveResourceIdConsideringLocalePrefix to deriveResourceIdConsideringLocalePrefixAndContract and add the contract as an argument to deriveResourceId and change the pseudo code this way:
function deriveResourceIdConsideringLocalePrefixAndContract(prefix, resourceName,
libraryName) {
var localePrefix = getLocalePrefix();
for (var contract : getLibraryContracts()) {
var result = deriveResourceId(contract, prefix, resourceName, libraryName, localePrefix);
// If the application has been configured to have a localePrefix, and the resource
// is not found, try to find it again, without the localePrefix.
if (null == result && null != localePrefix) {
result = deriveResourceId(contract, prefix, resourceName, libraryName, null);
}
if(result != null) {
return result;
}
}
// try without a contract
var result = deriveResourceId(null, prefix, resourceName, libraryName, localePrefix);
if (null == result && null != localePrefix) {
result = deriveResourceId(null, prefix, resourceName, libraryName, null);
}
}
function deriveResourceId(contract, prefix, resourceLoader,
resourceName, libraryName, localePrefix) {
var resourceVersion = null;
var libraryVersion = null;
var resourceId;
if (null != localePrefix) {
prefix = localePrefix + ‘/’ + prefix;
}
if (null != contract) {
prefix = contract + ‘/’ + prefix;
}
… // the rest stays as is.
}
What do we do with createResourceFromId? I think it should support contracts too.
> LU> Is it possible to use @ResourceDependency annotation to load a resource
> LU> inside a resource library contract implementation? if the answer is yes, we need
> LU> to do modifications in createResource() methods (META-INF/contracts is an
> LU> alternate package type).
>
> Yes, it is possible to do that.
>
> [...]
>
> EB> SECTION: changes to the ui: facelet tags
>
> EB> <ui:composition> and <ui:decorate> will have an additional attribute,
> EB> contract. If present, that name is taken to indicate that the named
> EB> template must be used from the named resource library contract. If such
> EB> a template is not found, it is an error, even if there is such a
> EB> template available outside of contract.
>
> FC> If the contract were just a prefix for the resources, we could
> FC> simply reference the template absolutely (including the prefix).
>
> LU> but if that so, there is no definition of the contract, which means
> LU> the reusability will be limited. I'm not saying that we cannot do
> LU> that, but in this case, I think it is clear this concept helps to
> LU> keep things in order from start.
>
> I understand the desire for that simplicity, but I'd rather formalize it
> with an attribute. It's more toolable that way.
OK.
Ciao Frank