Or could you prepare an patch, Paul? 2017-12-28 17:53 GMT+01:00 Thomas Andraschko <[email protected]>:
> I hope that leo can help here. > > > Am Donnerstag, 28. Dezember 2017 schrieb Paul Nicolucci : > >> Any updates here? We should work to make a decision on this soon so we >> can get 2.3.0 completed. >> >> Any thoughts on what changes are required? >> >> Thanks, >> >> Paul Nicolucci >> >> >> [image: Inactive hide details for Thomas Andraschko ---12/09/2017 >> 03:08:38 PM---I asked why this feature is actually needed and become]Thomas >> Andraschko ---12/09/2017 03:08:38 PM---I asked why this feature is actually >> needed and become further feedback: The idea is that OmniFaces >> >> From: Thomas Andraschko <[email protected]> >> To: MyFaces Development <[email protected]> >> Date: 12/09/2017 03:08 PM >> Subject: Re: Dev Discussion - JSF 2.3 >> ResourceVisitOption.TOP_LEVEL_VIEWS_ONLY >> different between MyFaces and Mojarra >> ------------------------------ >> >> >> >> I asked why this feature is actually needed and become further feedback: >> >> The idea is that OmniFaces will eventually throw out it's now proprietary >> FacesViews feature in favour of the standardised APIs, and perhaps will >> only add some extra things. >> Perhaps it's possible to add a clarification to the spec for JSF 2.4 >> about the intention of the various view hints, with some examples etc. >> >> 2017-12-08 20:28 GMT+01:00 Thomas Andraschko < >> *[email protected]* <[email protected]>>: >> >> I talked with Arjan about that topic. >> Here is the statement: >> >> I: >> How was it desinged? I actually agree with Leo and the MyFaces impl >> that views are actually only files that can be served by the browser and >> they must be placed inside the webapp directory. Templates, includes and >> else can be placed in jars but is not a "view" actually. >> WDYT? >> >> Arjan: >> The above is not entirely correct. The design (contract) is that it >> returns whatever the installed VDL(s) recognise as a view. The feature >> should delegate to the VDL and negotiate with that. For instance, the >> default Facelet VDL is able to load views from a jar since JSF 2.2. >> >> Another custom VDL might load views from a database, from an external >> folder, or what have you. >> >> So the idea is not to make any assumptions about where views van >> reside or not, but ask the VDL, and return whatever the VDL supports. >> >> >> WDYT Leo? >> >> 2017-11-24 2:00 GMT+01:00 Leonardo Uribe <*[email protected]* >> <[email protected]>>: >> Hi >> >> I think MyFaces behavior is correct here. The reason is you will >> never add views inside META-INF or WEB-INF folders, but you could add >> templates there. But a template is not a view. That is what I understand >> with "top level views". >> >> regards, >> >> Leonardo Uribe >> >> 2017-11-23 19:41 GMT-05:00 Thomas Andraschko < >> *[email protected]* <[email protected]>>: >> I think we should align myfaces here. A issue + patch would be >> great. >> >> >> Am Samstag, 18. November 2017 schrieb Paul Nicolucci : >> The javadoc for ResourceVisitOption.html says the following: >> >> *https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/ResourceVisitOption.html* >> >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__javaee.github.io_javaee-2Dspec_javadocs_javax_faces_application_ResourceVisitOption.html&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=n-2RUhyQkncKQNTGKy9UmSKIHKSZzEVYEqiy1H7hEwA&m=dXsCs4V2Evbu59Npakfxsz9tC6S4wyYSQBgwBj0dmTw&s=HIb7TRcn2ip64lyIIpODzOYa1lrZKkFjl9IwRzRHMUk&e=> >> >> public static final *ResourceVisitOption* >> >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__javaee.github.io_javaee-2Dspec_javadocs_javax_faces_application_ResourceVisitOption.html&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=n-2RUhyQkncKQNTGKy9UmSKIHKSZzEVYEqiy1H7hEwA&m=dXsCs4V2Evbu59Npakfxsz9tC6S4wyYSQBgwBj0dmTw&s=HIb7TRcn2ip64lyIIpODzOYa1lrZKkFjl9IwRzRHMUk&e=> >> TOP_LEVEL_VIEWS_ONLY >> Only visit resources that are top level views, i.e. views that can >> be used to serve a request as opposed to those that can only be used >> for >> includes. >> >> Thanks, >> >> Paul Nicolucci >> >> >> [image: Inactive hide details for Thomas Andraschko ---11/18/2017 >> 07:22:32 AM---Did you checked the spec texts? 2017-11-17 19:56 >> GMT+01]Thomas >> Andraschko ---11/18/2017 07:22:32 AM---Did you checked the spec texts? >> 2017-11-17 19:56 GMT+01:00 Paul Nicolucci <[email protected]>: >> >> From: Thomas Andraschko <[email protected]> >> To: MyFaces Development <[email protected]> >> Date: 11/18/2017 07:22 AM >> Subject: Re: Dev Discussion - JSF 2.3 >> ResourceVisitOption.TOP_LEVEL_VIEWS_ONLY different between MyFaces >> and Mojarra >> ------------------------------ >> >> >> >> Did you checked the spec texts? >> >> 2017-11-17 19:56 GMT+01:00 Paul Nicolucci <*[email protected] >> <[email protected]>*>: >> Hello, >> >> I was testing out the ResourceHandler.getViewResources() >> today and I noticed that we have quite a behavior different >> between the two >> implementations. >> >> Take the following application for example: >> >> testApplication >> - /depth2/index.xhtml >> -META-INF/index.xhtml >> -WEB-INF/index.xhtml >> - index.xhtml >> - test >> >> Mojarra getViewResources( call with ResourceVisitOptions ) >> /index.xhtml /depth2/index.xhtml >> >> Mojarra getViewResources ( call without ResourceVisitOptions >> ) >> /index.xhtml /depth2/index.xhtml META-INF/index.xhtml >> WEB-INF/index.xhtml >> >> MyFaces getViewResources( call with ResourceVisitOptions ) >> /index.xhtml /depth2/index.xhtml >> >> MyFaces getViewResources( call without ResourceVisitOptions ) >> /index.xhtml /test /depth2/index.xhtml >> >> In MyFaces if we use the ResourceVisitOptions then we filter >> out any views that don't contain a valid suffix ( in the above >> case /test >> ). In addition MyFaces never returns any views in WEB-INF and >> META-INF >> >> In Mojarra if we use the ResourceVisitOptions then anything >> in WEB-INF and META-INF is not included. In addition Mojarra >> never returns >> any views without a valid suffix. >> >> I think we need a dev discussion to determine if we want to >> stick with our current behavior or change it. >> >> Thanks, >> >> Paul Nicolucci >> >> >> >> >> >> >> >>
