Hi
I remember a discussion long time ago about if a resource library
contract should contain views or not. The documentation you should
take a look is the javadoc of ResourceHandler.createViewResource. It
says this:
"... The ViewDeclarationLanguage calls this method when it needs to
load a view from a persistent store, such as a filesystem. This method
is functionality equivalent to createResource(java.lang.String), but
all callsites that need to load VDL views must use this method so that
classes that want to decorate the ResourceHandler in order to only
affect the loading of views may do so without affecting the processing
of other kinds of resources, such as scripts and stylesheets. ..."
"... The default implementation must look for the resource in the
following places, in this order.
- Considering resource library contracts (at the locations specified
in the spec prose document section Resource Library Contracts in the
Request Processing Lifecycle chapter).
- Considering the web app root.
- Considering faces flows (at the locations specified in the spec
prose document section Faces Flows in the Using JSF in Web
Applications chapter). ..."
The argument that Frank had in that time was that sometimes you need
to bundle some functionality along with the contract (resource library
contracts are meant for modularize appearance, what if you want to
make that appearance customizable for users), so you need to allow
load views from resource library contracts. It is also more simple for
users. But I had my concerns about that, because views are something
special. Frank's point of view proved to be more convenient and that
is what we have now.
A view placed under a resource library contract can override any other
view. That's something explicit in the javadoc and intentional.
I think there is no conflict here. Citing the slide 35 from Ed Burns
presentation here:
http://es.slideshare.net/edburns/jsf-22-26091922
* Allow composing a JSF app as a collection of modules:
- Faces Flow modularize behavior
- Resource Library Contracts modularize appearance
* Well defined contract for each
The problem is "Faces Flow" does not fully modularize all behavior of
a JSF app. There are some cases where a module is defined by a couple
of loosely coupled views , but there is no associated context that
joins all views like in a Faces Flow.
One proposal could be this:
- Allow load views from /views folder
- Allow load views from META-INF/views from the classpath.
- Allow load views from a resource library contract like this:
<contract-name>/views . This would make the libraryName "views"
reserved, so we need to take care about this to do not leak views from
createResource(...) (potential security hazard).
- Keep the existing rules as is.
From spec perspective, the changes should be done in
ResourceHandler.createViewResource(...).
regards,
Leonardo Uribe
2015-02-03 11:36 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
> Hi,
>
> On Tue, Feb 3, 2015 at 4:22 PM, Frank Caputo <frank_at_frankcaputo.de> wrote:
>> /contracts can have any resource, thus it can have top level views. From a technical perspective a view is just a facelet. Currently a view can be replaced in a contract.
>
> Okay, so I was mistaken there then. Thanks for the correction.
>
> But isn't this a problem then? All examples and actually the spec
> itself refers to it as a "resource library", and saying that it
> contains files that would otherwise reside within the resources
> directory (which default to /resources).
>
> The spec specifically says in 2.7:
>
> "A resource library contract is a resource library, as specified in
> the preceding section,
> except that *instead of residing in the resources directory* of the
> web-app root, or in the META-INF/resources
> JAR entry name in a JAR file, it resides in the contracts directory of
> the web-app root, or in the META-
> INF/contracts JAR entry name in a JAR file." (emphasis mine)
>
> If I now have the following structure:
>
> WebRoot
> contracts
> contract1
> test.xhtml (with output "contract file")
> test.xhtml (with output "root file")
> WEB-INF
> faces-config.xml (empty)
>
> and request say localhost:8080/test.jsf then it outputs "contract file".
>
> However, if I have the following structure:
>
> WebRoot
> resources
> test.xhtml (with output "resource file")
> test.xhtml (with output "root file")
> WEB-INF
> faces-config.xml (empty)
>
> and request localhost:8080/test.jsf again then it outputs "root file".
>
> So I would say that the spec text is perhaps not entirely correct, as
> contracts do not just serve files that would otherwise reside within
> /resources?
>
> The same holds for templates of course, which can't normally be served
> from /resources either, but that is, more or less, explained in
> 10.1.3:
>
> "A configurable set of Facelet VDL views in the application will be
> able to declare themselves to be template-clients of any template in a
> resource library contract."
>
> The same section also says:
>
> "When useContract.war is deployed, the runtime will discover that
> siteLayout.jar is a resource library contract
> and make its contents available for template clients."
>
> So here it explicitly says that the content is made available to
> *template clients*. It doesn't speak about those files becoming
> available as top-level views.
>
> To sum up, I looks like 2.7 is potentially not entirely consistent
> with 10.1.3, and both do not mention anywhere that views in contract
> may be top-level views as well (but I could of course have missed
> something).
>
> What do you think?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>>
>> Ciao Frank
>>