Yep, re-reading it, that's exactly what you said.  Sorry
for the misunderstanding.  So this is a tougher nut
to crack.  I can imagine some hacks to try to
instantiate the rendering context on the fly, but
nothing really obvious and bulletproof comes to mind.

I think we need a JIRA issue...

-- Adam


On 2/20/07, Stefan Podkowinski <[EMAIL PROTECTED]> wrote:
Hi Adam

I already have trinidad working with facelets. The problem is it only
runs with trinidad as the *default rendering kit*. Defining trinidad
as the rendering kit per page does *not* work. Please see my first
mail for details.

On 2/19/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> Oh, I see.  You're using Facelets.  You need to configure things
> a bit differently than without Facelets.  Check out:
>
> http://wiki.apache.org/myfaces/Facelets_with_Trinidad
>
> -- Adam
>
>
> On 2/16/07, Stefan Podkowinski <[EMAIL PROTECTED]> wrote:
> >
> > 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
> > > >
> > >
> >
>

Reply via email to