Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Facelets/VDL
    • Labels:
      None
    • Environment:

      JSF 2.1.24

      Description

      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]

        Activity

        Hide
        Ed Burns added a comment -

        Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

        Show
        Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
        Hide
        Ed Burns added a comment -

        I'm concerned about the performance implications of your suggestion.

        Show
        Ed Burns added a comment - I'm concerned about the performance implications of your suggestion.

          People

          • Assignee:
            Unassigned
            Reporter:
            aplossystems
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 15 minutes
              15m
              Remaining:
              Remaining Estimate - 15 minutes
              15m
              Logged:
              Time Spent - Not Specified
              Not Specified