Search parent naming containers for component

[eclipse-faces-bot]

It's logical that when you have a tree of components you shouldn't look in the child naming containers for a relative id name as duplicates are likely to exist. However it doesn't seem logical to not look in the parent container and take the first avaiable component with that relative id as no duplicates will exist in a single layer above.

I've therefore made an simple update in the UIComponentBase that will look in the parent for the component for the relative id. There's a number of places that this will work more intuitively, especailly for people with a more basic knowledge of JSF. The first is when using relative id's within a dataTable or repeat, all of a sudden relative ids no longer work which is quite confusing if you don't know why. The second is that when you pass a relative id into a custom component it won't be able to find it as the custom component will do the find method relative to itself. The other is when using cc.clientId or similar within a custom component (granted you can just easily add a : beforehand in this scenario). I'm sure there's other times as well where this would come in useful.

Below is the code that would need to be put in place of the existing code, there's only about 5 lines of code actually changed, I've already run this through the JSF tests and everything appeared to pass :

[code]

// Identify the base component from which we will perform our search UIComponent base = this; UIComponent initialBase = null; if (expr.charAt(0) == sepChar) { // Absolute searches start at the root of the tree while (base.getParent() != null)

{ base = base.getParent(); }

// Treat remainder of the expression as relative expr = expr.substring(1); } else if (!(base instanceof NamingContainer)) { // Relative expressions start at the closest NamingContainer or root while (base.getParent() != null) { if (base instanceof NamingContainer)

{ break; }

base = base.getParent(); } initialBase = base; }

// Evaluate the search expression (now guaranteed to be relative) UIComponent result = null; String[] segments = expr.split(SEPARATOR_STRING); for (int i = 0, length = (segments.length - 1); i < segments.length; i++, length--) { result = findComponent(base, segments[i], (i == 0)); // the first element of the expression may match base.id // (vs. a child if of base) if (i == 0 && result == null && segments[i].equals(base.getId()))

{ result = base; }

if (result Unable to render embedded object: File (= null && () not found.(result instanceof NamingContainer)) && length > 0)

{ throw new IllegalArgumentException(segments[i]); }

if (result == null)

{ break; }

base = result; }

if( result == null && initialBase != null && initialBase.getParent() != null )

{ initialBase.getParent().findComponent(expr); }

[/code]

Environment

JSF 2.1.24

[eclipse-faces-bot]

• Issue Imported From: https://github.com/javaee/javaserverfaces-spec/issues/1200
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: Unassigned

[eclipse-faces-bot]

@glassfishrobot Commented Reported by aplossystems

[eclipse-faces-bot]

@glassfishrobot Commented @edburns said: Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

[eclipse-faces-bot]

@glassfishrobot Commented @edburns said: I'm concerned about the performance implications of your suggestion.

[eclipse-faces-bot]

@glassfishrobot Commented This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-1200

[eclipse-faces-bot]

@tandraschko Commented We should think about to just close this one. This task can be easily done via search expressions in 2.3: update="@id(myId)" - also it's really not fast and we should avoid to enhance UICOmponent#findComponent for this case.

[eclipse-faces-bot]

@arjantijms Commented Good idea to close this, not sure who has the rights to do that these days. @edburns ?