Hi
I don't think an interface could work, because it is the parent, not the
child who defines the iteration strategy. It is a fact that we reuse the
same component instances for different rows (UIData).
regards,
Leonardo Uribe
2015-01-12 9:13 GMT-05:00 manfred riem <manfred.riem_at_oracle.com>:
> Hi Hanspeter,
>
> I am trying to formalize it for the RenderPhase only, which would mean
> stating something like the following:
>
> 1. ElCacheable would be defined by an interface
> 2. ElCacheable would operate only in RENDER_RESPONSE
> a. Which means a component would not be allowed to change the value of
> an EL expression
> b. For an iterating component it would not cache and thus not
> implement ElCacheable
> c. For components not implementing the ElCacheable interface it would
> operate as if it was not cacheable.
> 3. Add a getter / setter that stores elCacheable on the UIComponent
>
> Am I missing something here?
>
> Thoughts?
> Manfred
>
>
>
> On 1/9/15, 5:18 PM, Hanspeter wrote:
>
> 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
>>>
>>>
>>
>