Ticket #1950 (new enhancement)

Opened 6 weeks ago

Last modified 6 weeks ago

Tree should show the expand/collapse icon only if node actually has children

Reported by: -Sami- Owned by: Marko Gronroos
Priority: major Milestone: IT Mill Sponsored Backlog
Component: Server-side framework Version: 5.2.5
Keywords: Cc:
Known Issue description:
Hours estimate: Deadline (dd.mm.yyyy):
Known Issue version (since): Known Issue title:
Hours done: Depends to:
Affects documentation: no
Known Issue workaround:
Affects release notes: no Contract:

Description

I'd like that the Tree component would automatically show the expand/collapse icon if the Item node has children and hide it if not. Now it shows the icon for every node unless explicitly denied.

At the moment our own Container.Hierarchical implementation handles this when adding Items, but it would be great if the Tree itself would do this. And we have situations where if we use some non-hierarchical Container with the Tree. Then we have to manually call setChildrenAllowed(, false) for each item, which isn't nice..

This could be a settable option for the Tree. And maybe the visibility of the icon shouldn't be directly based on the Item's capability to have children (set/areChildrenAllowed) as it's now (right?). I think the capability to have children is a separate thing from actually having children at the moment.

Change History

Changed 6 weeks ago by Teemu Pontelin

This issue was actually discussed earlier in ticket #1630, which was closed with a wontfix resolution. See the ticket for an explanation by Matti.

Changed 6 weeks ago by Joonas Lehtinen

  • priority changed from undefined to major
  • component changed from undefined to Server-side framework
  • milestone set to IT Mill Sponsored Backlog

We must take into account the case where no children are sent to client, but the data source actually has (maybe dynamically generated) children for the node.

Still this feature should be doable (might require API additions).

Changed 6 weeks ago by -Sami-

(Sorry for not finding the earlier ticket and posting a duplicate..)

I understand that explanation, but why not possible to add this as settable optional thing? Default could be the current behavior. This way it could be used in situations when we know the Item tree is fully loaded in the Container.

Note: See TracTickets for help on using tickets.