myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <simon.kitch...@rhe.co.nz>
Subject Re: A simple alternative to the ExtensionFilter
Date Fri, 23 Mar 2007 04:55:25 GMT
noah wrote:
> On 3/22/07, Simon Kitching <simon.kitching@rhe.co.nz> wrote:

>> The rendered state of a component depends upon the rendered state of all
>> its parent components, so the rendered property of many components in
>> the page would need to be evaluated.
> 
> But if you determine that the parent is not rendered, you can skip the
> rest of that branch, right?

Yes, if you're walking the tree from the top down.

I was thinking about the approach where each component on creation finds 
the ancestor HEAD component and adds itself to a list on that object so 
that the HEAD component can easily find components to check when it 
renders. In that case, for each component it would be necessary to walk 
up the ancestor tree to the UIViewRoot, then walk back down that chain 
again evaluating the rendered attribute on each node (giving up if any 
is false). Doable, but seems odd - and potentially inefficient unless 
some kind of map is kept of what nodes have already been evaluated to 
avoid calling rendered multiple times.

As you say, an alternative is to walk the entire tree when the head tag 
is rendered (not just the children of the head) looking for components. 
In that case, when rendered is false for a particular node then its 
children can be skipped. It does feel rather odd for a component to go 
looking at components other than its children when rendering.

> 
>> And in some cases evaluating a
>> rendered EL expression can have side-effects; yes it is poor style to do
>> so but it's not uncommon.
> 
> Really? I'm fairly certain I've seen (in my logs, debugging, etc.)
> most of the EL expressions in a page get evaluated multiple times.
> Does the spec not say anything about EL being consistent?  Relying on
> EL being evaluated only once seems like it has to violate some aspect
> of the spec. I always assumed that my expression would be evaluated
> multiple times and cached appropriately (i.e. when it involved a DB
> hit or whatever) for this very reason.  Most of my experience is with
> Facelets, does JSP do it differently?
> 
> At the very least, if the spec doesn't say that the EL for rendered
> must not be evaluated more than once, relying on that behavior seems
> like it might not be a good idea. But I can't find the relevant
> portion of the spec right now.

I can't remember anything in the spec that explicitly states it, but I 
would expect rendered should be evaluated:
  * once before processDecodes
  * once before processValidators
  * once before processUpdates
  * once before encodeBegin

In particular, the "once before encodeBegin" should really be true; 
there doesn't seem to be a good reason to call it multiple times during 
the render phase.

You're right though that people shouldn't *rely* on this. However I'm 
definitely guilty of having used the rendered property of a 
<t:inputHidden> or similar to trigger bean initialisation, and assumed 
it occurs before EL expressions on other tags are invoked, ie that the 
rendering does a normal depth-first traversal. I might even have assumed 
that it happens only once during the render phase..

Cheers,

Simon

Mime
View raw message