I'm in favor of removing it, now that I have the big picture, even though it makes my article somewhat obsolete. Thanks for the thorough explanation, Cay.<br><br><br>david<br><br>2010/2/4 Dan Allen <span dir="ltr"><<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a>></span><br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><div></div><div class="h5">On Thu, Feb 4, 2010 at 6:16 PM, Andy Schwartz <span dir="ltr"><<a href="mailto:andy.schwartz@oracle.com" target="_blank">andy.schwartz@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Cay Horstmann wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Originally, cc meant "the current composite component" as opposed to "the composite component in this implementation section. For example, consider a login component<br>
<br>
<composite:implementation><br>
<util:labeledInputField label="Username" value="#{<a href="http://cc.attrs.name" target="_blank">cc.attrs.name</a>}"/><br>
<util:labeledInputField label="Password" value="#{cc.attrs.password}"/><br>
</composite:implementation><br>
<br>
Way back when, this wouldn't have worked IF util:labeledInputField was a composite component as well. In that case, cc would have been the labeledInputField, and it would have been necessary to use #{<a href="http://cc.parent.attrs.name" target="_blank">cc.parent.attrs.name</a>} to get the login component's name attribute.<br>
<br>
That was fragile. It required the implementor to know which components are composite. Stuff would break if you changed the implementation of a utility component--e.g. from a regular util:labeledInputField to a composite one or the other way around.<br>
<br>
The EG then changed the definition of cc,<br>
</blockquote>
<br></div>
I am really glad that we changed this. :-)<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
but apparently nobody remembered to remove the special handling of cc.parent. It is in the spec and the implementation.<br>
</blockquote>
<br></div>
Okay, this seems like an oversight to me. I have logged the following issue to request that we remove this from the spec:<br>
<br>
<a href="https://javaserverfaces-spec-public.dev.java.net/issues/show_bugcgi?id=741" target="_blank">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=741</a><br>
<br>
Any objections to making this change in the MR?<br>
<br>
Cay - thanks so much for the detailed explanation. Finally understand how we ended up with the currently specified behavior!<font color="#888888"></font></blockquote></div></div><div><br>Indeed. Thanks to your careful analysis we can make an informed decision, rather than one from the hip.<br>
<br>I pretty much had the same thought about cc.parent when I was reading David's article. It looked neat, but struck me as fragile. When the need arises to do that type of relative referencing, it probably indicates that you need a new aggregate composite component that is responsible for passing the information downwards (to nested components).<br>
<br>I'm in favor of removing it based on this reasoning.<br><br>-Dan<br></div></div><font color="#888888"><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br>
<br><a href="http://mojavelinux.com" target="_blank">http://mojavelinuxcom</a><br>
<a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br><a href="http://www.google.com/profiles/dan.j.allen" target="_blank">http://www.google.com/profiles/dan.j.allen</a><br>
</font></blockquote></div><br>