Hi,
> Am 04.03.2015 um 23:10 schrieb Edward Burns <edward.burns_at_oracle.com>:
>
>>>>>> On Thu, 26 Feb 2015 11:06:39 +0100, Frank Caputo <frank_at_frankcaputo.de> said:
>
> EB> Conceptually, I do not look at the Facelet files in a contract as a top
> EB> level view. Thus, I would be in favor of tightening the spec to say
> EB> that Facelet files in a contract must not be loadable as top level
> EB> views.
>
> EB> Frank, are you ok with that?
>
> FC> Unfortunately a customer of mine is using this functionality. They
> FC> have a contract for mobile clients and they need the possibility to
> FC> replace complete views. This is the project, from which resource
> FC> library contracts derived. So I would not delete this functionality.
>
> If we put this feature behind the famous "2.3" switch, could you accept
> it then?
Will we deprecate the possibility to replace whole views in contracts? If not, I’m OK with it.
> AT> The second problem is that in Facelets top level views, includes,
> AT> templates, etc all have the same extension; .xhtml. The runtime cannot
> AT> automatically make a distinction between what are top level views, and
> AT> what are other Facelets artefacts and in fact what are just files with
> AT> an .xhtml extension not being related to JSF at all. This again
> AT> introduces some security concerns, like /resources/mycomposite.xhtml
> AT> being requestable via a URL, even when it's not intended to be
> AT> requested as such.
>
> The absence of a specific filename for Facelet template clients vs.
> Facelet views was intentional, to ease adoption. I stand 100% behind
> this choice for simplicity.
So we will not differentiate between views and other facelets?
> Coming back to the core issue of 1359-views, here is the latest
> proposal.
>
> * Modify the spec for ResourceHandler.createViewResource() to replace the
> text "Considering the web app root." with the following:
>
> "Considering the value ResourceHandler.WEBAPP_VIEWS_PARAM_NAME
> property."
>
> * Add a new constant on ResourceHandler
>
> WEBAPP_VIEWS_PARAM_NAME = "javax.faces.WEBAPP_VIEWS_DIRECTORY"
>
> If a context-param with the param name equal to the value of
> WEBAPP_RESOURCES_DIRECTORY_PARAM_NAME exists, the runtime must
> interpret its value as a path, relative to the web app root, where VDL
> views must be located. This param value must not start with a "/",
> though it may contain "/" characters. If no such <context-param>
> exists, or its value is invalid, the effective value depends on the
> version of the WEB-INF/faces-config.xml file. If the version is 2.3
> or greater, the effective version is "WEB-INF/views". Otherwise the
> effective value is the empty string "“.
I did not yet understand 100%, what will be in the views folder? Only views or templates or includes or simply all of them? If it is the latter, I’d propose to call it facelets.
> * Include a promiment note in the changelog section of the spec calling
> out this opt-in non-backward-compatible change and what to do to "get
> the old behavior back".
>
> I'll note that this new constant has an inconsistent value with its
> siblings WEBAPP_CONTRACTS_DIRECTORY_PARAM_NAME and
> WEBAPP_RESOURCES_DIRECTORY_PARAM NAME. One could argue that we should
> have defined those as WEB-INF/resources and WEB-INF/contracts
> (respectively) in the first place. If you want to argue that, you may
> create a thread with
>
> Subject: WEBAPP_{CONTRACTS,RESOURCES}_DIRECTORY Discussion
>
> Personally, I'm content to live with these as they are and advise people
> to set them to be WEB-INF/contracts and WEB-INF/resources manually.
If this is all about relocation of files without losing functionality (like replacing entire views in contracts), I’m completely OK with it.
Ciao Frank