True, but it should only be invoked when the renderer(kit) changes, right? That shouldn't happen in most cases. And in the case when it does, we pay a penalty and the page is a bit slower. Doesn't sound like a big deal to me...?
Regards, Jan-Kees 2011/5/13 Jakob Korherr <[email protected]> > OK great, thanks Leo! > > > 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? > > we could use visitTree(), but note that this could be very expensive ;) > > Regards, > Jakob > > 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? > > > >> 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? > > > > Kočičák > > > >> > >> regards, > >> > >> Leonardo > >> > >> 2011/5/13 Martin Koci <[email protected]>: > >> > Hi, > >> > > >> > trinidad caches Renderer instance in UIXComponentBase so they at least > >> > suppose that rendererType cannot change during one render/response and > >> > no need for evaluate it in every getRendererType() call - see > >> > MYFACES-3144. > >> > > >> > Other libs I'll check. > >> > > >> > Regards, > >> > > >> > Kočičák > >> > > >> > Jakob Korherr píše v Pá 13. 05. 2011 v 16:44 +0200: > >> >> Hmm, ok. > >> >> > >> >> I also can't think of a scenario where you would use something like > >> >> this right now. But I'll think of it and do some research.. > >> >> > >> >> Martin, could you take a look at some of the prominent JSF component > >> >> libs (like Primefaces, Trinidad, Tomahawk, Tobago, RichFaces, > >> >> IceFaces) and search in their code for something like this? If you > >> >> don't find anything there, then it should be pretty safe to remove > the > >> >> ValueExpression support from rendererType! > >> >> > >> >> Regards, > >> >> Jakob > >> >> > >> >> 2011/5/13 Martin Koci <[email protected]>: > >> >> > Hi, > >> >> > > >> >> > from spec: > >> >> > > >> >> > .. "Because the components themselves store only a rendererType > property > >> >> > (a logical identifier of a particular Renderer)" .. > >> >> > > >> >> > > >> >> > rendererType = " Identifier of the Renderer instance (from the set > of > >> >> > Renderer rendererType String instances supported by the RenderKit > >> >> > associated with the component tree we are processing." > >> >> > > >> >> > "The default value of the rendererType property must be set to" ... > >> >> > (always String in spec) > >> >> > > >> >> > > >> >> > JavaDoc: setRendererType - rendererType = Logical identifier of the > type > >> >> > of Renderer to use, or null for components that render themselves > >> >> > > >> >> > It seems to me that rendererType is String-only, not > ValueExpression. > >> >> > Similar attributes are componentType and componentFamily -those are > >> >> > String-only I think. > >> >> > > >> >> > Internally in code I don't see > >> >> > component.setValueExpression("rendererType", ve). > >> >> > > >> >> > <a:component rendererType="#{bean.getRendererType}" /> is not > possible. > >> >> > > >> >> > > >> >> > > >> >> > About state saving and rendererType I found nothing. > >> >> > > >> >> > > >> >> > Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200: > >> >> >> Hi Martin, > >> >> >> > >> >> >> Have you checked the JSF 2.1 and 2.0 specs yet? > >> >> >> > >> >> >> Regards, > >> >> >> Jakob > >> >> >> > >> >> >> 2011/5/13 Martin Koci <[email protected]>: > >> >> >> > Hi, > >> >> >> > > >> >> >> > > >> >> >> > two questions : > >> >> >> > > >> >> >> > 1) can UIComponent.rendererType be ValueExpression? If yes, in > which > >> >> >> > situation is useful to use it? > >> >> >> > > >> >> >> > 2) should be rendereType saved during state saving? Each > component has > >> >> >> > setRendererType("com.foo.renderer") in constructor and/or VDL > calls > >> >> >> > setRendererType() after calling Application.createComponent() > >> >> >> > > >> >> >> > > >> >> >> > Please see MYFACES-3136 for details > >> >> >> > > >> >> >> > Thanks, > >> >> >> > > >> >> >> > > >> >> >> > Kočičák > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> > > >> > > >> > > >> > > > > > > > > > > -- > Jakob Korherr > > blog: http://www.jakobk.com > twitter: http://twitter.com/jakobkorherr > work: http://www.irian.at >
