On Tue, Sep 14, 2010 at 3:30 AM, Leonardo Uribe <
lu4242@gmail.com> wrote:
> 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
>