One more question: UIComponent.getClientId() uses Renderer.convertClientId
1) INVOKE_APPLICATION - action listener calls component.getClient() -> component generates client id with renderer1 + as next step actionListener changes renderKitId 2) RENDER_RESPOSE: renderer2 from new renderkit renders component with clientId from renderer1! Is that ok? Leonardo Uribe píše v Pá 13. 05. 2011 v 15:45 -0500: > Hi > > 2011/5/13 Martin Koci <[email protected]>: > > Leonardo Uribe píše v Pá 13. 05. 2011 v 14:59 -0500: > >> Hi > >> > >> +1 to both changes. > > > > That means: replace StateHelper with attribute as MYFACES-3136 suggests, > > right? > > That means change StateHelper.eval to StateHelper.get in > UIComponentBase.getRendererType() > > The point 3 it is not really necessary, because this property is part > of the full state, not the delta, which is the one that consume space > on server side state saving. I prefer keep using StateHelper but get > instead eval. > > > > >> I agree with you about rendererType is always an > >> String, there is not any mention on the spec saying rendererType could > >> receive EL expressions. If someone wants to change a renderer, it uses > >> a RenderKit wrapper or just define another RenderKitId to be used for > >> the current application. > >> > >> Please note this description of UIViewRoot.getRenderKitId : > >> > >> "... Return the render kit identifier of the RenderKit associated with > >> this view. Unless explicitly set, as in > >> ViewHandler.createView(javax.faces.context.FacesContext, > >> java.lang.String), the returned value will be null. ..." > >> > >> and setRenderKitId: > >> > >> "... Set the render kit identifier of the RenderKit associated with > >> this view. This method may be called at any time between the end of > >> Apply Request Values phase of the request processing lifecycle (i.e. > >> when events are being broadcast) and the beginning of the Render > >> Response phase. ..." > >> > >> So any caching must preserve this behavior. > > > > Thats very interesting, with this behaviour it is possible to change > > renderkit in actionListener for example. But it also means that renderer > > cannot be be cached UIComponentBase: > > > > 1) UIComponent.decode -> caches renderer > > 2) INVOKE_APPLICATION -> changes renderKit > > 3) UIComponent.encodeBegin -> uses old cached renderer > > > > but caching is valid for all encode* method then. Any ideas how to > > detect "this component will be rendered in this lifecycle" and cache > > renderer even for getClientId? stateManagement calls getClientId > > (checkIds) before component.encodeBegin. Can we use visitTree method for > > that? > > Cache as soon as you do the lookup, but clean it inside encodeAll > call. Note some code is necessary here if encodeAll is called multiple > times over the same instance (datatable or datalist case). Use a > simple variable to do the trick. > > Leonardo >
