I just tried the other way around by setting trinidad as default
render kit in faces-config.xml and <f:view ..
renderKitId="HTML_BASIC">. Afterwards the page renders fine but I'm
getting an error on submit:
javax.faces.application.ViewExpiredException:
viewId:/jsfexamples/examples-simple-1.jsf - View
/jsfexamples/examples-simple-1.jsf could not be restored.
com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:180)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
If I remove trinidad as default rendere kit, submit works too.
Whats also a bit concerning here is that with trinidad as default
render kit, the following hidden field is also generated every time
for the form tag, not taking <f:view renderKitId=".."> into account:
<input type="hidden" name="javax.faces.RenderKitId"
value="org.apache.myfaces.trinidad.core" />
On 2/16/07, Adam Winer <[EMAIL PROTECTED]> wrote:
Stefan,
We have a JSF 1.2 branch of Trinidad which is well tested,
and contains (nearly) the latest code.
http://svn.apache.org/repos/asf/incubator/adffaces/branches/faces-1_2-070201/
The only bad news is that you currently have to build
it yourself - we don't have an automated build going for
this branch.
(FYI, we rebranch every once in awhile, and the URL changes
when we do.)
-- Adam
On 2/15/07, Stefan Podkowinski <[EMAIL PROTECTED]> wrote:
> Hello
>
> Currently it does not seem to be possible to use trinidad with jsf1.2
> ri and facelets and not having trinidad declared as default rendering
> kit.
>
> Removing
>
>
<default-render-kit-id>org.apache.myfaces.trinidad.core</default-render-kit-id>
>
> from faces-config.xml and adding the render kit declaration to the view root
>
> <f:view ... renderKitId="org.apache.myfaces.trinidad.core">
>
> will break the view handling process with the following error:
>
> java.lang.IllegalStateException: No RenderingContext
> at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin(CoreRenderer.java:159)
> at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeBegin(UIXComponentBase.java:668)
> at
org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1209)
> at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeAll(UIXComponentBase.java:721)
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:890)
> at
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:571)
> at
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:182)
> at
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
>
>
>
> After doing some debuging, I came to the conclusion that this must be
> due to the trinidad ViewHandlerImpl.renderView() method
> implementation. The problem is the way the ViewHandlerImpl wraps the
> delegate, but needs to setup the RenderingContext before the delegate
> is executed. Creating the RenderingContext is currently done by
> CoreRenderKit.encodeBegin(). But this won't never happen in this case,
> because facelets did not parse the page including the <f:view
> renderKitId..> element yet, so we don't know which render kit to use
> before calling the facelets delegate!
>
> So here's whats happening in ViewHandlerImpl:
> 160: ExtendedRenderKitService cannot be found because trinidad is not
> the default anymore
> 172: CoreRenderKit will not be called to setup RenderingContext (thread local)
> 182: delegation to FaceletViewHandler
> afterwards
>
org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin(CoreRenderer.java:159)
> fails on non initialized thread local.
>
> What do you think? Is there a chance to reimplement
> ViewHandlerImpl.renderView() so this problem could be resolved? Any
> possible side effects?
>
> Thanks,
> Stefan
>
