[jsr-314-open-mirror] [jsr-314-open] Should the ViewDeclarationLanguage be responsible to indicate if a viewId can be created?

[Leonardo Uribe]

Hi

The current algorithm to check if a view with a specific viewId does not
allow to add or extends a new ViewDeclarationLanguage using a new
prefix/extension.

This issue is related to

https://issues.apache.org/jira/browse/MYFACES-2628 Facelets ResourceSolver
can't work

and

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1567

The problem resides on a "hidden" requeriment for Restore View Phase
algorithm, that is ignored silently. On mojarra, this is the code on
MultiViewHandler.getViewDeclarationLanguage:

    public ViewDeclarationLanguage getViewDeclarationLanguage(FacesContext
context,
                                                              String viewId)
{

        String actualViewId = derivePhysicalViewId(context, viewId, false);
        return vdlFactory.getViewDeclarationLanguage(actualViewId);

    }

Now on myfaces is this:

    @Override
    public ViewDeclarationLanguage getViewDeclarationLanguage(
            FacesContext context, String viewId)
    {
        // return a suitable ViewDeclarationLanguage implementation for the
given viewId
        return _vdlFactory.getViewDeclarationLanguage(viewId);
    }

The difference is subtle, but very, very important. This method is called
from many locations, but only once (from RestoreViewPhase) it is passed the
"raw" viewId. To "derive" the physical viewId it is required to know if
prefix or suffix mapping is used and if suffix mapping is used, try to check
if a view "resource" exists or not with different derived ids with the
extensions configured ".xhtml .jsp".

javax.faces.view.facelets.ResourceResolver documentation says this:

"... Provide a hook to decorate or override the way that Facelets loads
template files. A default implementation must be provided that satisfies the
requirements for loading templates as in Pre-JSF 2.0 Facelets ..."

So, in theory it is possible to override ResourceResolver interface and
serve resources from a different location. But the algorithm in
MultiViewHandler.derivePhysicalViewId does not take into account this
interface, so it try to check if the view "resource" exists on the same
location and fails.

The solution proposed is add a method on ViewHandler,
ViewDeclarationLanguageFactory and ViewDeclarationLanguage called:

    public boolean existsViewId(String viewId)

So the VDL can indicate if a viewId exists or not. In this way, on Facelets
VDL we can check if a viewId exists using the ResourceResolver instance. It
is curious that ViewDeclarationFactory implementation has some methods that
indicate if a vdl can handle a viewId or not (it is not the same, but
similar). I'm not done too much work on this issue, but it could be good to
take a look at this one. It could be good to open an issue on the spec for
this one too (if no objections I'll open an issue for this one, but better
to ask first).

Suggestions are welcome.

regards,

Leonardo Uribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100913/1c91f059/attachment-0002.html