[fleXive] comes with a tree component, accessible via the
TreeEngine
interface with means to create and manage tree based structures and attach FxContent instances to tree
nodes. There are actually 2 logically (and physically in terms of used database tables) distinct trees: a
live
(published) and an
edit
(preview) tree. There always exists a virtual root node with node Id
1
defined in
FxTreeNode.ROOT_NODE
. If there is no content manually attached, [fleXive] will create an instance of type
Folder
and attach it. The same thing applies if a content instance that is attached to a node is removed: it will be
replaced by an autogenerated
Folder
instance. An exception is removal of a content linked to a leaf node. In this case the tree node will be removed
as well.
The tree does not implement its own security but makes use of the permissions of the attached content instances. This means in practice that only those nodes can be seen to which the user has at least read access to. As a consequence any child nodes attached to a node that a user has no read permission for will not be accessible [3] . The same security constraints apply to queries.
Currently the following scripts for tree engine events can be created:
AfterTreeNodeAdded
AfterTreeNodeRemoved
BeforeTreeNodeRemoved
AfterTreeNodeActivated
BeforeTreeNodeActivated
AfterTreeNodeFolderReplacement
Please refer to the section called “Scripting Engine” and the section called “Script administration” for further information.
The tree component supports two different modes: Live andEdit.
In typical web applications a single mode (the edit mode) might be sufficient, but when it comes to applications that are publishing-centric - or if there should be a way to preview how the tree will look before it goes live - using two modes simplifies development a lot.
Activation is the process of copying a node (optionally with all subnodes) from the edit to the live tree. The dirty flag helps to distinguish between the live and the edit tree. Anything changed in the edit tree that is not activated on the live tree is flagged as dirty. As a consequence no node on the live tree can ever be flagged as dirty! If a node with a particular id was removed in the live tree and still exists in the edit tree, then this node and all its children will be flagged as dirty in the edit tree. All nodes in the edit tree that do not exist in the live tree are flagged dirty as well. The dirty flag basically helps to visualize which nodes in the edit tree differ from nodes in the live tree.
Removing a node from the live tree will also remove all of its subnodes. This ensures data consistency between the two trees.
The tree API tries to be as intuitive and simple as possible. Please see the API documentation for further reference as we'll just cover some basics in this chapter.
Example 6.21. Creating a new tree node attached to the root node
//Lookup the tree interface TreeEngine tree = EJBLookup.getTreeEngine(); //create new node FxTreeNodeEdit node = FxTreeNodeEdit.createNew("NodeName"); FxString label = new FxString(false, "NodeLabel"); node.setLabel(label); //create the node long id1 = tree.save(node); //load it FxTreeNode node_loaded = tree.getNode(id1); //delete it tree.delete(node_loaded, false)
Example 6.22. Clear both Live and Edit Tree in the groovy console
com.flexive.shared.EJBLookup.treeEngine.clear(com.flexive.shared.tree.FxTreeMode.Edit)
com.flexive.shared.EJBLookup.treeEngine.clear(com.flexive.shared.tree.FxTreeMode.Live)
[3] That applies to user interfaces if the tree was loaded from a parent of the inaccessible node. But since any node can act as the root node (which has to be passed when loading the tree) it is possible to see such nodes, if the path from the root node to the desired node is accessible