>>>>> On Tue, 3 Feb 2015 16:22:28 +0100, Frank Caputo <frank_at_frankcaputo.de> said:
FC> /contracts can have any resource, thus it can have top level
FC> views. From a technical perspective a view is just a
FC> facelet. Currently a view can be replaced in a contract.
>>>>> On Tue, 3 Feb 2015 17:36:40 +0100, arjan tijms <arjan.tijms_at_gmail.com> said:
AT> Okay, so I was mistaken there then. Thanks for the correction.
AT> But isn't this a problem then? All examples and actually the spec
AT> itself refers to it as a "resource library", and saying that it
AT> contains files that would otherwise reside within the resources
AT> directory (which default to /resources).
[...]
AT> To sum up, I looks like 2.7 is potentially not entirely consistent
AT> with 10.1.3, and both do not mention anywhere that views in contract
AT> may be top-level views as well (but I could of course have missed
AT> something).
>>>>> On Tue, 3 Feb 2015 22:35:29 -0500, Leonardo Uribe <leonardo.uribe_at_irian.at> said:
LU> The argument that Frank had in that time was that sometimes you need
LU> to bundle some functionality along with the contract (resource library
LU> contracts are meant for modularize appearance, what if you want to
LU> make that appearance customizable for users), so you need to allow
LU> load views from resource library contracts. It is also more simple for
LU> users. But I had my concerns about that, because views are something
LU> special. Frank's point of view proved to be more convenient and that
LU> is what we have now.
LU> A view placed under a resource library contract can override any other
LU> view. That's something explicit in the javadoc and intentional.
Yes, that is true, but Arjan is asking if we should allow loading a
Facelet file within a contract *as* at top level view, rather than as an
overlay on top of a top level view.
Conceptually, I do not look at the Facelet files in a contract as a top
level view. Thus, I would be in favor of tightening the spec to say
that Facelet files in a contract must not be loadable as top level
views.
Frank, are you ok with that?
LU> The problem is "Faces Flow" does not fully modularize all behavior of
LU> a JSF app. There are some cases where a module is defined by a couple
LU> of loosely coupled views , but there is no associated context that
LU> joins all views like in a Faces Flow.
Leonardo, if you want to discuss this one further, you may start a
separate thread.
>>>>> On Wed, 4 Feb 2015 14:57:32 +0100, Frank Caputo <frank_at_frankcaputo.de> said:
FC> I dont like the /views folder, because this forces JSF developers to
FC> structure their facelets technically. If the developers work domain
FC> driven, they usually structure by the domain. E.g. a folder /account
FC> will have all facelets belonging to the domain account including the
FC> corresponding views.
>>>>> On Wed, 4 Feb 2015 15:30:28 +0100, arjan tijms <arjan.tijms_at_gmail.com> said:
AT> I think they can largely still do that, /views just becomes an
AT> alternative root folder, albeit for top level views only.
AT> So
AT> /views
AT> /account
AT> order.xhtml
AT> /admin
AT> dashboard.xhtml
Yes. The WEB-INF/views directory is really just a new place for what
used to be just in the web app root.
>>>>> On Tue, 24 Feb 2015 11:26:27 +0100, Frank Caputo <frank_at_frankcaputo.de> said:
FC> IMO 1359 brings no benefit to the spec. It just adds complexity to
FC> the whole resource handling, which is already complicated enough.
Hi Frank, you're right in pointing out 1359-views adds little value.
Just the same, for the two reasons cited in the following text, I can
support it.
FC> Arjan, can you please explain a little bit more, what are the benefits?
>>>>> On Tue, 24 Feb 2015 12:03:45 +0100, arjan tijms <arjan.tijms_at_gmail.com> said:
AT> The first is that in the default configuration JSF now has a *source
AT> code exposure vulnerability*. [...]
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.
Strictly speaking, these two items are different aspects of the same
concern.
One other aspect not mentioned is alignment with the MVC spec.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 8 days til DevNexus 2015
| 18 days til JavaLand 2015
| 28 days til CONFESS 2015