Hi Leonardo,
The encodeBegin method has access to the parent component, so it can
determine the parent ElCacheable from it. If the parent is not an
ELCacheable instance the component itself cannot be either, otherwise it
can look its getter.
Regards,
Manfred
On 1/12/15, 11:40 AM, Leonardo Uribe wrote:
> 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
> <mailto: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
>> <mailto: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 <mailto: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>
>> <mailto:manfred.riem_at_oracle.com>
>> Reply-To:
>> jsr344-experts_at_javaserverfaces-spec-public.java.net
>> <mailto:jsr344-experts_at_javaserverfaces-spec-public.java.net>
>> Organization: Oracle Corporation
>> To: jsr344-experts_at_javaserverfaces-spec-public.java.net
>> <mailto:jsr344-experts_at_javaserverfaces-spec-public.java.net>
>> CC: Max Starets <max.starets_at_oracle.com>
>> <mailto:max.starets_at_oracle.com>, Andy Schwartz
>> <andy.schwartz_at_oracle.com> <mailto: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
>>
>>
>>
>