Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-5587

In tree views, expand/collapse controls get redecorated by jstree and make the tree look funny

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 2.0.0-b4, 2.0
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-5904Make Proposition tree control more like the Rule tree control
      KULRICE-5238build agenda tree UI components
      KULRICE-5353jstree plugin isn't being loaded anymore
      KULRICE-4715Provide support for Tree Controls
      KULRICE-5269KRAD test views: expand/collapse should be links
      KULRICE-5903Text to make it more clear between Rule and Proposition tree sections.
      KULRICE-5509Expand / Collapse UI problems
      KULRICE-12007Cache Manager tree layout confusing
      KULRICE-11394DatePicker does not work in a tree.
      KULRICE-13122Tree group invokes nested property for every node which causes performance issues
    • Rice Module:
      KRAD
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      the default data group for a tree node is currently a plain old Group, which has an expand/collapse control on it (which is a html link in the page). the jstree plugin sees that link and decorates it w/ an icon, which makes for a funny looking tree with extra folder icons.

        Activity

        Hide
        Peter Giles (Inactive) added a comment -

        I committed a "fix" which changes the Group to a GroupBodyOnly and so the extra folder icons don't show up. However, if someone used a node prototype with something in the data group that contained an expand/collapse control, this issue would rear its head and their tree would look funny. So there is still an underlying issue that I've only wallpapered over here.

        Show
        Peter Giles (Inactive) added a comment - I committed a "fix" which changes the Group to a GroupBodyOnly and so the extra folder icons don't show up. However, if someone used a node prototype with something in the data group that contained an expand/collapse control, this issue would rear its head and their tree would look funny. So there is still an underlying issue that I've only wallpapered over here.
        Hide
        Rice-CI User (Inactive) added a comment -

        Integrated in rice-trunk-nightly #178 (See http://ci.rice.kuali.org/job/rice-trunk-nightly/178/)
        KULRICE-5587: In tree views, expand/collapse controls get redecorated by jstree and make the tree look funny

        • changing the default data group to a GroupBodyOnly to avoid weird extra folder icons
        Show
        Rice-CI User (Inactive) added a comment - Integrated in rice-trunk-nightly #178 (See http://ci.rice.kuali.org/job/rice-trunk-nightly/178/ ) KULRICE-5587 : In tree views, expand/collapse controls get redecorated by jstree and make the tree look funny changing the default data group to a GroupBodyOnly to avoid weird extra folder icons
        Hide
        Jessica Coltrin (Inactive) added a comment -

        double-tagging with 2.0.0-b3 for review.

        Show
        Jessica Coltrin (Inactive) added a comment - double-tagging with 2.0.0-b3 for review.
        Hide
        Brian Smith (Inactive) added a comment -

        Shouldn't we just be using GroupWithBodyOnly, also we are going to change the default behavior of group to not have disclosure by default.
        OR alternatively have a Group specifically for tree nodes so future enhancements dont conflict, I cant imagine this is the only thing that might have issue because of doing it this way.
        Question: Why aren't we using a separate java class from Group for tree node beans?

        Show
        Brian Smith (Inactive) added a comment - Shouldn't we just be using GroupWithBodyOnly, also we are going to change the default behavior of group to not have disclosure by default. OR alternatively have a Group specifically for tree nodes so future enhancements dont conflict, I cant imagine this is the only thing that might have issue because of doing it this way. Question: Why aren't we using a separate java class from Group for tree node beans?
        Hide
        Scott Gibson (Inactive) added a comment -

        Peter's solution is correct - the tree view should handle the topmost level of disclosure.
        Whether or not disclosure groups can be nested under that will be something to test when a use case arises.

        Show
        Scott Gibson (Inactive) added a comment - Peter's solution is correct - the tree view should handle the topmost level of disclosure. Whether or not disclosure groups can be nested under that will be something to test when a use case arises.
        Hide
        Jessica Coltrin (Inactive) added a comment -

        Closing since these items are now in the release notes.

        Show
        Jessica Coltrin (Inactive) added a comment - Closing since these items are now in the release notes.

          People

          • Assignee:
            Unassigned
            Reporter:
            Peter Giles (Inactive)
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel