Changes between Version 1 and Version 2 of Ticket #16690, comment 5


Ignore:
Timestamp:
Feb 11, 2013, 6:21:08 PM (9 years ago)
Author:
spaquette
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #16690, comment 5

    v1 v2  
    11Regarding the mayHaveChildren aspect: if I'm reading what you've said correctly, this implies if any node *could* have children, regardless of whether or not it has them right now, then one would need to have mayHaveChildren just return true.
    22
    3 This introduces a new problem, though. If mayHaveChildren always returns true, all  nodes, including leaves, show an expando icon. In the case of a leaf, when someone clicks on it, the icon vanishes. While you can override getIconClass to change the leaf icon to a leaf-like icon if there aren't children, but you can't override the presence of the expando icon and its click action without modifying Tree itself. There's a use-case for having all leaves behave and look like leaves until they have children, rather than as 'potential branches' ala exploring files and folders.
     3This introduces a new problem, though. If mayHaveChildren always returns true, all  nodes, including leaves, show an expando icon. (They also default to folder icons, but you can override getIconClass to deal with that.) In the case of a 'leaf' folder, when someone clicks on it, the expando icon vanishes. You can't override the presence of the expando icon and its click action, so there's no way to stop this behavior. There's a use-case for having all leaves behave and look like leaves until they have children, rather than as 'potential branches' ala exploring files and folders whose content status is unknown.
    44
    55If mayHaveChildren is intended to return true if a node may ever have children, can we have a way to also override the presence of the expando icon, as is done with getIconClass?
    66
    77(This is looking like it's related to #9413.)
     8
     9(Edited so what I'm getting at is more clear.)