Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (athena.apache.org: domain of martin.kocicak.koci@gmail.com
 designates 209.85.214.53 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:in-reply-to:references:content-type:date:message-id
         :mime-version:x-mailer:content-transfer-encoding;
        b=eoA69OtsO1LnK6IarRpqmri3oCmKsHQcq0ByGJ1C7DEaskGnIdqM7tj0dBChi+C3tO
         QL3in8f/HxlPTiDWzdtx1f2uuXxMMJmF2APD/tQc8iQgJsml4IM8IIf3Sok8zwY+rzVQ
         LhDP249gUnBpBNWjj6zYy0lWPQqaYEopyefAc=
Subject: Re: [core] Can UIComponent.rendererType be ValueExpression ?
 (MYFACES-3136)
From: Martin Koci <martin.kocicak.koci@gmail.com>
To: MyFaces Development <dev@myfaces.apache.org>
In-Reply-To: <BANLkTik+FNOuDZxzOxiSatk7Kq8KfRX0nQ@mail.gmail.com>
References: <1305295555.11056.15.camel@markoc-desktop>
	 <BANLkTikEw1MedJNi0HzWgwbOs9GROUwY8g@mail.gmail.com>
	 <1305297481.11056.39.camel@markoc-desktop>
	 <BANLkTinEibKcUP7jF4u4Q+j8-nJ2Vt1g+g@mail.gmail.com>
	 <1305316137.11056.52.camel@markoc-desktop>
	 <BANLkTik+FNOuDZxzOxiSatk7Kq8KfRX0nQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 13 May 2011 22:29:33 +0200
Message-ID: <1305318574.11056.67.camel@markoc-desktop>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit

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 <martin.kocicak.koci@gmail.com>:
> > 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 <martin.kocicak.koci@gmail.com>:
> >> > 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 <martin.kocicak.koci@gmail.com>:
> >> >> > 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
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
>