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?
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.
> 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?
> 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.
> 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?
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.
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.
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).
> 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.
Naturally MyFaces is free to do what it wants with the
org.apache.myfaces.JSP_SUFFIX parameter.
Hope this clarifies things.
Kind regards,
Arjan Tijms
>
> regards,
>
> Leonardo Uribe
>