Hi
LU> +1. Just remember each string should have the following structure:
LU>
LU> [contract-library-name]:[contract-resource-prefix]
LU>
LU> For example
LU>
LU> my.custom.resourceLibraryContract:implA
LU>
LU> and so on.
FC> I thought the contractLibraryName and resourcePrefix is the same.
LU> The contractLibraryName defines which contract implementation the
LU> resourcePrefix relates to. In that way, resourceLibraryContracts has
LU> both the contracts to use and the implementations of those contracts.
EB> This one totally threw me for a loop as well. I didn't see it coming.
EB>I don't see a compelling reason for this complexity so I'm going with
EB>Frank's logic there is only resourceLibraryContract sand it's a simple
EB>List<String>.
I was thinking on the following structure (just take it as another
point of view,
the idea is take a look at different strategies to see its trade-offs, I'm also
mixing all ideas discussed until this moment):
/* Declaration */
META-INF/contracts/my.resource.library.contract/template.xhtml
META-INF/contracts/my.resource.library.contract/css/styles.css
META-INF/contracts/my.resource.library.contract/js/script.js
META-INF/contracts/my.resource.library.contract/img/background.png
/* Implementation */
META-INF/contracts/my.resource.library.contract/siteLayout/
META-INF/contracts/my.resource.library.contract/siteLayout/template.xhtml
META-INF/contracts/my.resource.library.contract/siteLayout/css/styles.css
META-INF/contracts/my.resource.library.contract/siteLayout/js/script.js
META-INF/contracts/my.resource.library.contract/siteLayout/img/background.png
The top level template.xhtml declares insertion and the default
resources points, and the
one in siteLayout folder can extend the base one and override the
insertion points.
In the page, it can be used like this:
<ui:composition>
<f:view contract="my.resource.library.contract:siteLayout">
<ui:decorate template=”/template.xhtml”>
<ui:define name=”title”>#{msgs.contactsWindowTitle}</ui:define>
<ui:define name=”main”>
<h:commandButton value=”next” action=”page2” />
</ui:define>
<ui:define name=”footer”>#{msgs.contactsWindowFooter}</ui:define>
</ui:define>
</ui:decorate>
</f:view>
</ui:composition>
or if the contract is set using other option:
<ui:composition template=”/template.xhtml”>
<ui:define name=”title”>#{msgs.contactsWindowTitle}</ui:define>
<ui:define name=”main”>
<h:commandButton value=”next” action=”page2” />
</ui:define>
<ui:define name=
”footer”>#{msgs.contactsWindowFooter}</ui:define>
</ui:composition>
(maybe it comes in handy to allow ui:composition to have contract attribute?)
If you want another implementation of the same contract you should use
this structure:
META-INF/contracts/my.resource.library.contract/newSiteLayout/
META-INF/contracts/my.resource.library.contract/newSiteLayout/template.xhtml
META-INF/contracts/my.resource.library.contract/newSiteLayout/css/styles.css
META-INF/contracts/my.resource.library.contract/newSiteLayout/js/script.js
META-INF/contracts/my.resource.library.contract/newSiteLayout/img/background.png
The advantage of provide a library name is that you can classify
multiple contract implementations and be sure that all of them
provide the same "insertion points". Also there is a simple
"inheritance" relationship between the implementation and the
declaration, so you can create a new contract just overriding
the resources provided by default, so for create a new
implementation you don't need to write all the boilerplate
over and over.
Without this classification, you can have multiple contracts, but
there is no way to know if contract implementation is compatible
with other implementation or not.
Note this option does not exclude the alternative already proposed,
and instead it looks like a natural extension. To differentiate between
a contract implementation and a "contract family" inside
META-INF/contracts, we could use a naming convention over
the folder (all directories ended with .contract belongs to a "contract
family").
Maybe this proposal is just too much for something than should be
plain and simple from start, or maybe it is worth to do it, because it
provides both a simple mode and a more formalized mode (maybe
oriented to contract authors that requires a more structured approach).
regards,
Leonardo Uribe
2012/11/13 Edward Burns <edward.burns_at_oracle.com>:
>>>>>> On Wed, 14 Nov 2012 00:49:50 +0100, Ian Hlavats <ian_at_tarantulaconsulting.com> said:
>
> IH> Hey guys,
> IH> I'm late on the reply but I want to say, I think it's crucially important that wherever we decide to define the resource contracts, this definition should support EL.
>
> IH> For example:
>
> IH> <f:view contracts="#{cms.resourceContracts}">
> IH> ...
> IH> </f:view>
>
> IH> If we move the resource contract configuration to faces-config.xml
> IH> wouldn't we lose the ability to use EL expressions?
>
> The latest thinking in that PDF I just shared does allow it to be in
> <f:view> and with EL.
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/