noah wrote:
On 3/22/07, Simon Kitching <[EMAIL PROTECTED]> 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
