In Cloud CMS, there are no hard and fast rules regarding association types between nodes. And so, when dealing with things like tree structures, you usually have to first make some assumptions about the kinds of relationships between nodes that you want to traverse. For arbitrary relationships and traversals around nodes, Cloud CMS provides traversal methods which are a bit more intensive to use.
However, if you're using typical a:child relationships between nodes (which is what Cloud CMS uses for folder-based relationships), then we provide an out-of-the-box tree API so that you can have a web component on a page render back a list of folders and sub-folders.
The exact API is:
GET /repositories/{repositoryId}/branches/{branchId}/nodes/{nodeId}/tree
And on the JS driver, the method is:
Node.loadTree(config, callback)
Retrieves a tree structure for nested folders starting at this node (as the root).
@chained node
@public
@param {Object} config - { "leafPath": "<leafPath>", "basePath": "<basePath>", "containers": true }
@param {Function} callback - the callback function to be passed the resulting tree object structure
loadTree: function(config, callback)
{
...
}
This method should be called on a starting node (usually the root node). You can then define a "basePath" which is the path offset from which you will retrieve children or expand the tree. For example, you might first get the root node and then load the tree for it (which lists all sub-items under the root node):
branch.rootNode().loadTree({
"basePath": "/",
"containers": true
}, function(tree) {
var children = tree.children;
...
});
The "containers" option lets you indicate whether you want to retrieve folders instead of documents. In some tree controls, you may want to list folders on the left-hand side, for example, and then show documents on the right hand side.
The "leafPath" option, if provided, also lets you indicate a path that should be 100% expanded. Usually, you'd use this if you're reloading the tree from the root and a user has already navigated to a document. That way, the loaded tree comes back with the document path completely loaded.
This is what we provide at the moment. If this isn't sufficient or if there are ways that we can improve it, let us know. Another option is to retrieve child associations and child relatives yourself using methods like:
GET /repositories/{repositoryId}/branches/{branchId}/nodes/{nodeId}/children
GET /repositories/{repositoryId}/branches/{branchId}/nodes/{nodeId}/associations
Or their respective JavaScript methods. These hand back the association objects (which relate two nodes together):
- Node.associations()
- Node.incomingAssociations()
- Node.outgoingAssociations()
And these hand back the nodes related to a source node:
- Node.listRelatives()
- Node.queryRelatives()
The latter are probably the most powerful in terms of brewing your own solution. But that said, let us know what can be improved within our own API so that we can best support your development needs.