NT> it would be way less overhead, if there would be a reference back from NT> the inputText to the outputLabel that is actually stored with the NT> inputText and not just logically defined by the 'for' attribute of NT> label. If a reference to the outputLabel would be stored in a collection NT> with the inputText by setting the 'for'-attribute on outputLabel it NT> could be just taken from there and wouln't require runtime-walk of the NT> component-tree to be retrieved. On Tue, Sep 15, 2009 at 3:24 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: DA> +1. Exactly what I was thinking. DA> DA> It appears we have two correlated issues here. I've found a need for the DA> backreference in the past. It can be linked at build time. Of course, DA> programmatic access would need to be aware of it if the tree is modified in DA> a way that breaks the reference. That should be mentioned in the issue DA> report, not necessarily solved here. MM> FWIW, MyFaces originally implemented a solution for this, but then MM> dropped it from the IMPL and moved it to Tomahawk, to remain MM> compatible. It seems to me that this is a request for a general purpose component metadata solution. Right now we have this in the spec: 3.6.2.1 Composite Component Metadata In the current version of the specification, only composite UIComponents must have component metadata. It is possible that future versions of the specification will broaden this requiremnt so that all UIComponents must have metadata. I've opened issue 717 for this, and added this specific usecase. I'll continue to scan for this topic in my traversal of old messages, but just in case I miss something, please add additional requirements to the issue. Ed -- | ed.burns(a)sun.com | office: 408 884 9519 OR x31640 | homepage: | http://ridingthecrest.com/