How so? It is just calling one component up?
Manfred
On 1/12/15, 12:06 PM, Leonardo Uribe wrote:
> Hi Manfred
>
> MR>> The encodeBegin method has access to the parent component
>
> The problem is do that will increase the algorithm complexity. We need to
> keep it on lineal complexity (O(n)), otherwise the optimization will not
> be effective.
>
> regards,
>
> Leonardo Uribe
>
> 2015-01-12 12:44 GMT-05:00 manfred riem <manfred.riem_at_oracle.com
> <mailto:manfred.riem_at_oracle.com>>:
>
> 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
>>>
>>>
>>>
>>
>