Hi Martin
Yes, this one was settled on JSF 2.1 in this way:
1. Add this method to ViewHandler.
String deriveLogicalViewId(FacesContext context, String rawViewId)
2. Fix ViewHandler.getViewDeclarationLanguage(FacesContext context, String
viewId) method javador to specify the viewId to be used is the one after
call deriveLogicalViewId
It was solved under this topic:
[jsr-314-open] 490-XmlViews Processing JSPX files as Facelets
best regards,
Leonardo Uribe
2011/2/7 Martin Marinschek <mmarinschek(a)apache.org>
Hi Leonardo,
was this ever settled? Did you get the feedback you need? Did you open an
issue?
best regards,
Martin
On Tue, Sep 14, 2010 at 3:30 AM, Leonardo Uribe <lu4242(a)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
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces