Hi Kito
In that case you should set the custom MyFaces param with the extension
required. I'm not concern about that.
The point is I do not see how to make the current spec work without that
change. Leaving the previous behavior is not possible if VDL.getViews(...)
and ViewHandler.getViews(...) is properly handled. In other words, if the
user call ViewHandler.getViews(...), this method should get all VDLs and
call VDL.getViews(...) in each one of them, which means
ResourceHandler.getViewResources
will be called as many times as VDLs that depends on files (by default two).
Please note I'm implementing this stuff in MyFaces from scratch, and even
if JSP is deprecated, that doesn't mean the code should be let without the
changes required to make it work properly. It is a nuisance the extra
param? yes, but it is also necessary.
regards,
Leonardo Uribe
2017-03-23 6:21 GMT-05:00 Kito Mann <kito.mann_at_virtua.com>:
> Leonardo,
>
> I'm a bit concerned about changing the functionality of the JSP VDL in
> MyFaces. Sounds like it might break backwards compatibility. I guarantee
> someone out there is using a ".foo" file as JSP page, and they would have
> to know this and add it to web.xml in order to keep things from breaking
> with when upgrading to 2.3 (unless I'm missing something).
>
> ___
>
> Kito D. Mann | @kito99 | Author, JSF in Action
> Web Components, Polymer, JSF, PrimeFaces, Java EE training and consulting
> Virtua, Inc. | virtua.tech
> JSFCentral.com | @jsfcentral | knowesis.io - fresh Web Components info
> +1 203-998-0403 <(203)%20998-0403>
>
> * See me speak at the ng-conf April 5th-8th: http://bit.ly/2mw7HBj
> <http://bit.ly/2kr0fWI>
> * Listen to the Enterprise Java Newscast: http://enterprisejavanews.com
>
>
> On Mon, Mar 13, 2017 at 9:04 PM, Leonardo Uribe <leonardo.uribe_at_irian.at>
> wrote:
>
>> Hi
>>
>> 2017-03-13 19:27 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
>>
>>> Hi,
>>>
>>> On Tue, Mar 14, 2017 at 12:28 AM, Leonardo Uribe <
>>> leonardo.uribe_at_irian.at> wrote:
>>>
>>>> The problem is with the introduction of VDL concept, each VDL is in
>>>> fact bound to
>>>> an extension.
>>>>
>>>
>>> I'm not 100% sure of this. Practically, often yes, but theoretically?
>>>
>>>
>> If the VDL uses files a source to create JSF views, yes. At least the
>> VDLs available
>> in JSF at this moment, but I agree you can imagine one without that
>> concept.
>>
>>
>>> I thought the ViewHandler simply should know internally what views a VDL
>>> handles. This can be distinguished by extension, but also by some other
>>> means, i.e. by consulting a config file that lists all view IDs a certain
>>> VDL is supposed to handle, or a directory, or perhaps, who knows, even any
>>> arbitrary pattern in the view ID.
>>>
>>> I.e. ViewHandler#getViewDeclarationLanguage(FacesContext context,
>>> String viewId) and ViewDeclarationLanguageFactory
>>> .getViewDeclarationLanguage(String viewId) are the magic that makes
>>> this possible.
>>>
>>> The input here is a "viewId", and then the factory can do whatever
>>> analysis it wants based on this viewId to find and return the right VDL.
>>>
>>>
>> Yes.
>>
>>
>>>
>>>
>>>> Right now, JspViewDeclarationLanguage does not have any check in this
>>>> part, so any
>>>> resource file is considered a view, which logically is wrong.
>>>>
>>>
>>> I'm not really sure if I understand what you mean here. Could you
>>> rephrase this or provide an example?
>>>
>>>
>> There is a method in javax.faces.view.ViewDeclarationLanguage called
>> viewExists(...) with this description:
>>
>> "... Tests whether a physical resource corresponding to the specified
>> viewId exists.
>>
>> The default implementation uses ResourceHandler.createViewReso
>> urce(javax.faces.context.FacesContext,
>> java.lang.String) to locate the physical resource. ..."
>>
>> Since JspViewDeclarationLanguage does not override this method, any
>> resource in webapp folder will be
>> considered a view. There is no check for the extension.
>>
>> If you try for example:
>>
>> facesContext.getApplication().getViewHandler().getViewDeclarationLanguage(facesContext,
>> "/res/mycss.css");
>>
>> and the resource exists, JSF will return a JspViewDeclarationLanguage
>> instance.
>>
>> The idea is add a check in that location and in viewExists(...) to avoid
>> that, since getViews(...) requires to
>> return a list of the views that the VDL really can handle.
>>
>>
>>>
>>>
>>>> Of course, JSP was deprecated and is now considered legacy stuff.
>>>>
>>>
>>> Indeed, via the blanket statement that JSP is deprecated, Mojarra indeed
>>> doesn't handle JSP at all here. Perhaps this fact should have been made
>>> more clearer at the spec level. It would certainly be good to have as
>>> clarification for the next spec version.
>>>
>>>
>> It is not clear if "deprecate" JSP views means "no longer works" or
>> "works under your own resposibility" or "not removed but it will be soon".
>>
>> I'm +1 for remove it once for all in JSF 2.3, but it is not a big deal.
>> For now JSP related code remains in place.
>>
>>
>>>
>>>
>>>> But .jsp has not
>>>> been the only extension used for JSF/JSP. There are apps that uses
>>>> .jspx or .tiles
>>>> The point is there is nothing in the spec to define this, and the
>>>> binding between
>>>> the VDL and the extension is very important, specially when you see
>>>> hints like
>>>> ViewVisitOption.RETURN_AS_MINIMAL_IMPLICIT_OUTCOME, which aims to trim
>>>> the
>>>> extensions from the Stream.
>>>>
>>>
>>> Indeed, but does the spec really need to know about this or define this
>>> extension?
>>>
>>>
>> No. It is not considered a spec bug.
>>
>> The idea would be that the factory and probably the VDL knows a given VDL
>>> is handling say .jspx for JSP. When the user has a reference to a certain
>>> VDL (obtained in whatever manner), say the JSP VDL here, the user can query
>>> it for all the views it supports. RETURN_AS_MINIMAL_IMPLICIT_OUTCOME
>>> will then indeed in the case of the JSP VDL strip of the .jspx extension,
>>> as that will be the most minimal form that can be used as the implicit
>>> outcome for actions.
>>>
>>>
>> That's ok. The "implicit outcome" algorithm relies on
>> javax.faces.DEFAULT_SUFFIX, so it
>> tries one by one each suffix and then calling to
>> getViewDeclarationLanguage(...) and
>> viewExists(...).
>>
>>
>>> But the fact that .jspx needs to be stripped is done internally in the
>>> VDL implementation, so it can use any implementation specific (e.g. MyFaces
>>> specific or Mojarra specific) mechanism to find out that .jspx is the right
>>> extension to strip.
>>>
>>>
>>
>> Yes.
>>
>>
>>>
>>> The solution is as simple as add a web config parameter like
>>>> javax.faces.FACELETS_SUFFIX. In MyFaces I'm adding
>>>> org.apache.myfaces.JSP_SUFFIX
>>>> but I would like to set javax.faces.JSP_SUFFIX (but to do that we need
>>>> to agreed it
>>>> here).
>>>>
>>>
>>> I do think this is a good idea itself, and yes, in the past I've been
>>> wondering too why there's a javax.faces.FACELETS_SUFFIX but no
>>> javax.faces.JSP_SUFFIX, but I'm also afraid we can't just add
>>> a javax.faces.JSP_SUFFIX outside the spec (but Ed or Manfred would be able
>>> to confirm this).
>>>
>>>
>> Yes, I'm not suggesting to add it, only I wanted to mention it in order
>> to clarify it.
>>
>>
>>>
>>>
>>>> In my opinion the web config param is necessary to implement
>>>> VDL.getViews(...)
>>>> properly, but it can be considered a legacy implementation detail. It is
>>>> optional to include the config param in JSF spec.
>>>>
>>>
>>> My feeling is that the config param would not be needed based on what I
>>> explained above. As the somewhat hazy plans (at least from my side and
>>> subject to spec lead and EG approval) is to remove JSP support entirely,
>>> it's maybe not the best investment of time to spend much energy here.
>>>
>>>
>> Ok.
>>
>>
>>> Naturally MyFaces is free to do what it wants with the
>>> org.apache.myfaces.JSP_SUFFIX parameter.
>>>
>>>
>> Thanks for the clarifications.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>>> Hope this clarifies things.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>
>>>
>>
>