Hi
For me this is an implementation detail, but anyway in MyFaces it was
discovered a way to make it work without changes over the spec some years
ago. Old history to me.
regards,
Leonardo Uribe
2015-01-09 18:18 GMT-05:00 Hanspeter <hampidu_at_gmail.com>:
> Hi Experts.
>
> I think this is worth pushing +1.
>
> The multiple rendered attribute evaluation bothers most in the render
> phase because isRendered() is called by every UIComponent(Base).encode*
> method. So maybe a first step would be to improve the encode* methods such
> that for an encodeAll() cycle the rendered attribute is cached. That is
> possible with a few lines of code - I happily provide the changes.
>
> E.g. encodeAll() and/or encodeBegin() could enable renderedCaching,
> isRendered() stores the rendered result on a component private Boolean, and
> in encodeEnd() rendered caching is disabled and reset. That way without
> additional effort rendered is reset for the next iteration. But still this
> would reduce evaluate times by factor 3 to 4 per component encoding.
>
> I'm not sure whether rendered caching on a broader scope makes sense, e.g.
> for phases 2-5. In csJSF component library we did some rendered caching,
> but had to reset the cache once per phase and within iterating components
> as well. And I think rendered is rarely evaluated more often as it was
> reset in these execution phases.
>
> Best regards
> Hanspeter
>
>
>
> 2015-01-09 19:12 GMT+01:00 Bauke Scholtz <balusc_at_gmail.com>:
>
>> +1
>>
>> Ideally, the UIComponent#isRendered() should cache the value on a
>> per-phase and per-iteration basis. It would be awesome too if iteration
>> components implement a common interface or abstract class, which should
>> also simplify a lot of other things related to a.o. setting the currently
>> iterated item and state saving.
>>
>> Cheers, B
>>
>>
>> On Fri, Jan 9, 2015 at 7:00 PM, manfred riem <manfred.riem_at_oracle.com>
>> wrote:
>>
>>> Whoops, sending to right list. Please ignore it on the other.
>>>
>>> -------- Original Message -------- Subject: [jsr344-experts]
>>> [941-ReduceELCalls] DISCUSSION Date: Fri, 09 Jan 2015 11:51:14 -0600 From:
>>> manfred riem <manfred.riem_at_oracle.com> <manfred.riem_at_oracle.com> Reply-To:
>>> jsr344-experts_at_javaserverfaces-spec-public.java.net Organization: Oracle
>>> Corporation To: jsr344-experts_at_javaserverfaces-spec-public.java.net CC:
>>> Max Starets <max.starets_at_oracle.com> <max.starets_at_oracle.com>, Andy
>>> Schwartz <andy.schwartz_at_oracle.com> <andy.schwartz_at_oracle.com>
>>>
>>> Hi all,
>>>
>>> As we all know the number of times an EL expression is evaluated during
>>> render is higher than it could be.
>>>
>>> To see if there is a potential to reduce that number I want to ask the
>>> most important question first as it determines whether or not this issue is
>>> even worth pursuing?
>>>
>>> *Is it safe to assume that during rendering and not as a child of an
>>> iterating component the value of the EL expression will stay stable?*
>>>
>>> Regards,
>>> Manfred
>>>
>>>
>>
>