Hi I agree with Jakob. Client ids should be stable, because without that PSS will break (it relies on clientId to save delta state). I don't see any case where a renderkit provide a custom clientId generation.
regards, Leonardo 2011/5/14 Jakob Korherr <jakob.korh...@gmail.com>: > 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 >
