Good question, but I guess it is ok. At least the spec does not tell us otherwise, right?
Regards, Jakob 2011/5/13 Martin Koci <martin.kocicak.k...@gmail.com>: > > 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 <martin.kocicak.k...@gmail.com>: >> > 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 >> > > > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
