Created the issue in jira. https://issues.apache.org/jira/browse/ADFFACES-387 I'll hopefully be able to contribute a patch in the coming week, if I have the time for it.
On 2/20/07, Adam Winer <[EMAIL PROTECTED]> wrote:
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 > > > > > > > > > > > > > > >
