Hi Manfred
Well, you can make it work, but all that logic seems overkill to me. It
could work, but I doubt about its convenience against other tested
strategies for the same problem that are far more simple.
regards,
Leonardo Uribe
2015-01-12 15:07 GMT-05:00 manfred riem <manfred.riem_at_oracle.com>:
> Hi Leonardo,
>
> I disagree, as when the rendering starts in each encodeBegin it can get
> the elCacheable transientHelper attribute from the parent and then set is
> own elCacheable transientHelper attribute. And if you cannot find the
> elCacheable transientHelper attribute on the parent you err on the side of
> assuming it is not EL cacheable. And voila no going up many levels.
>
> Manfred
>
>
> On 1/12/15, 12:26 PM, Leonardo Uribe wrote:
>
> Hi
>
> It could be one, it could be many. The problem is the component doesn't
> know how many levels up should be checked to decide if there is an
> iteration, so it will be forced to go all levels to the top, over and over.
> There is no contextual information about the current iteration. I think it
> is quite easy to find examples where it will fail.
>
> regards,
>
> Leonardo Uribe
>
> 2015-01-12 13:08 GMT-05:00 manfred riem <manfred.riem_at_oracle.com>:
>
>> 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>:
>>
>>> 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>:
>>>
>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>