<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ken Paulsen wrote On 4/15/2009 12:14 PM ET:
<blockquote cite="mid:49E607E8.30205@sun.com" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Page author does:<br>
<br>
<my:echoComp value="#{foo.bar}"><br>
<br>
Suppose in echoComp def they map "compositeComponent.attributes" to
"foo". Then if the component attempts to evaluate the #{foo.value}
property, it (correctly, I assume) resolves to #{foo.bar}. However, if
the component author then attempts to evaluate that value and display
it, manipulate it, etc.... then it will incorrectly evaluate to (null)
(there is no "bar" attribute for this component). The managed bean
"foo" gets masked.<br>
</blockquote>
<br>
Hmm... I always thought that the VariableMapper for a ValueExpression
is determined when the ValueExpression is created, not when when the
ValueExpression is evaluated. So, in the above example, when the
ValueExpression for "#{foo.bar}" is created, it obtains a reference to
the current VariableMapper. This VariableMapper would not include the
compositeComponent's "foo" variable since that is not yet in scope.
Even if the "#{foo.bar}" ValueExpression is later evaluated within the
context of a composite component, it still uses its original
VariableMapper, and thus is not impacted by the presence of the "foo"
variable in the VariableMapper used by the composite component.<br>
<br>
In any case, seems like this will shortly be a moot point - I believe
that Ed will be sending out an alternate suggestion soon.<br>
<br>
Andy<br>
<br>
</body>
</html>