Left-side trees on explorer screens

[skateman]

After working months on the tree related code I am coming up with a concept of simplyfying the things. Let's divide our trees into two groups:

• Trees in the left sidebar
• Trees not in the left sidebar

The trees on the left sidebar have a limited set of functionalities compared to the ones on the right side, e.g. no checkboxes, no multiselect, simple event handling. Also they are used exclusively for navigation on the explorer screen while the other ones are can have different use cases.

My plan is to move apart the implementation of those trees from each other for more code sharing, better testing and easier componentization. There is already a lot of work in this area, most of the left side trees are being built by the build_accordions_and_trees that is fetching data from the features controller method that will be probably DSL-ized in the future.

Things to do:

• Rename, reorganize and clean up the X_TREE_NODE_CLASSES
• Convert trees under Optimize to use the features and build_accordions_and_trees
• Logically rename and reorganize TreeBuilder classes related to explorer screens
• Create a lightweight version of TreeBuilder for building the trees on the left side
• Create a component for rendering the tree on the client side

In the future I would like to see a DSL-like thing in the controllers for declaring the structure of these trees, something very similar to the one we're using in the topology services.

Summoning for comments @martinpovolny @karelhala and @himdel!

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

[JPrause]

@skateman is this still a valid issue? If yes, lease remove the stale label. If not can you close.
If there's no update by next week, I'll be closing this issue.

[skateman]

Closing this in favor of #5178