Implementing a tree node interface #5227
Currently we have a few constructs in our system that build a tree, but no proper interface for that. For example all menu items are forming a tree with nodes having a parent and children. Likewise with the categories and usergroups.
This PR is a result of the router changes that are currently being implemented. The idea is, that a generic router rule can work with data obtained by a specific component from its router and with this interface know what to do with it.
My main issue right now is, if I have all bases covered or if I am forcing already too much unto future developers. I took JCategoriesNode as an example and removed what was category specific. I also removed the getSibbling() method, since I fear it is too much for a generic node interface/class. In JCategoriesNode this method is meant to allow navigation between sibbling categories and having simple arrows left and right on a category page to navigate between them.
This PR is NOT ready for merging. It is meant for a place to discuss this idea and improve it. Right now I would not feel comfortable with this going into the core without some more thoughts by others.
In general I like the idea to define a treenode interface, because we can then vary the tree-implementations (some implementations are more optimal for reading, others for writing).
BUT: wouldn't JTreeNodeInterface be more accurate?
Hi @HermanPeeren, that is why I'm bringing this up here. We earlier had a JTree and a JNode and deprecated those... I honestly don't know the best way to go here. If nobody objects, we can rename it like that. I guess the only reason for me to call it JNodeInterface was to not have an empty folder named tree which only contains a folder named node in it...
Mmm, if you put it in hierarchical folders, then it would be called JNodeTreeInterface as a node of a tree is a special case of a more general node. And the superfolder doesn't have to be empty, for could have a definition of JNodeInterface. You would then have a JNodeTreeInterface extends JNodeInterface. The tree would then implement the restiction of a maximum of 1 parent.
Although that looks attractive at first sight, it is an endles road, for you could insert several other folders in between, like e.g. JNodeDAG (Directed Acyclic Graph). Besides that, there are node types that won't fit into such hierarchical type relations.
BTW: in the HTML DOM we also use the word node for tree nodes. The difference I see with a node in Joomla is, that the DOM is a tree and the word node to describe a part of the DOM is per definition only a tree node.
A way out of this swamp would be to just look to what we need and leave the rest out: you only want to better define trees in Joomla (hurray!), so you could call your node a a JTreeNodeInterface. Just as you did with your JNodeInterface, no empty folders or whatever, but just JTreeNodeInterface instead of JNodeInterface, leaving room for other node-types. The subject that you define, a tree, is the foldername: /tree. In that folder you can have a JTreeNodeInterface in libraries/cms/tree/nodeinterface.php. When using namespaces you would have some Joomla\Tree namespace: a package in which interfaces and implementations of tree-like structures are defined. And as we have seen with the DOM, within the scope of tree-types it is perfectly OK to talk about nodes then.