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.createViewResource(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
>>
>
>