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&gt; 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