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