Hello Leonardo,
So, how is Mojarra doing this without the context parameter?
___
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
* 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 Thu, Mar 23, 2017 at 9:53 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
wrote:
> 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
>>>>>
>>>>
>>>>
>>>
>>
>