Since you are telling me there are other tested strategies that are far
more simple can you elaborate?
Manfred
On 1/12/15, 2:53 PM, Leonardo Uribe wrote:
> 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
> <mailto: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
>> <mailto: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 <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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>