You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Martin Koci <ma...@gmail.com> on 2011/05/13 16:05:55 UTC
[core] Can UIComponent.rendererType be ValueExpression ?
(MYFACES-3136)
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
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Posted by Jan-Kees van Andel <ja...@gmail.com>.
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 <ja...@gmail.com>
> 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 <ma...@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?
> >
> >> 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 <ma...@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 <ma...@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 <ma...@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
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >
> >
> >
>
>
>
> --
> Jakob Korherr
>
> blog: http://www.jakobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.irian.at
>
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Posted by Jakob Korherr <ja...@gmail.com>.
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 <ma...@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?
>
>> 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 <ma...@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 <ma...@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 <ma...@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
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>
>
>
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Posted by Leonardo Uribe <lu...@gmail.com>.
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 <ja...@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 <ma...@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 <ma...@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
>
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Posted by Jakob Korherr <ja...@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 <ma...@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 <ma...@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
Re: [core] Can UIComponent.rendererType be ValueExpression ?
(MYFACES-3136)
Posted by Martin Koci <ma...@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 <ma...@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
>
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
2011/5/13 Martin Koci <ma...@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
Re: [core] Can UIComponent.rendererType be ValueExpression ?
(MYFACES-3136)
Posted by Martin Koci <ma...@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?
> 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 <ma...@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 <ma...@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 <ma...@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
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
>
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
+1 to both changes. 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.
regards,
Leonardo
2011/5/13 Martin Koci <ma...@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 <ma...@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 <ma...@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
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>>
>
>
>
Re: [core] Can UIComponent.rendererType be ValueExpression ?
(MYFACES-3136)
Posted by Martin Koci <ma...@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 <ma...@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 <ma...@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
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
>
>
>
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Posted by Jakob Korherr <ja...@gmail.com>.
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 <ma...@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 <ma...@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
>> >
>> >
>> >
>>
>>
>>
>
>
>
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [core] Can UIComponent.rendererType be ValueExpression ?
(MYFACES-3136)
Posted by Martin Koci <ma...@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 <ma...@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
> >
> >
> >
>
>
>
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Posted by Jakob Korherr <ja...@gmail.com>.
Hi Martin,
Have you checked the JSF 2.1 and 2.0 specs yet?
Regards,
Jakob
2011/5/13 Martin Koci <ma...@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
>
>
>
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at