Question

we would like to create a tree in MVVM pattern.

And this tree should have 2 directories passed by parameters.
The goal is to create a directory explorer, and we would like to have a “load on demand” when a child is opened in order to have better perfomance.

For moment, we find the exemple in documentation but it is incomplete :

public class TreeSelectionVM {

    private TreeModel<TreeNode<String>> itemTree;
    private String pickedItem;
    //omit getter and setter for brevity
}

<window apply="org.zkoss.bind.BindComposer"
    viewModel="@id('vm') @init('org.zkoss.reference.developer.mvvm.collection.TreeSelectionVM')">
    <tree id="tree" model="@bind(vm.itemTree) " width="600px"
    selectedItem="@bind(vm.pickedItem)">
        <treecols>
            <treecol label="name" />
            <treecol label="index" />
        </treecols>
        <template name="model" var="node" status="s">
            <treeitem open="@bind(node.open)">
                <treerow>
                    <treecell label="@bind(node.data)" />
                    <treecell label="@bind(s.index)" />
                </treerow>
            </treeitem>
        </template>
    </tree>
</window>

Should we manage the onOpen event ? or should we implements TreeModel and TreeNode methods (getChild & co) ?

Thank you.

Answer 1

Here is a more complete zk mvvm tree example which is along the lines of a directory explorer which does a load on-demand:

https://github.com/simbo1905/zktreemvvm

Just check it out with “git clone” then run it with:

mvn -Djetty.port=8080 package jetty:run

The code will start its own jetty server on a given port.

It uses Apache Commons VFS as an abstraction to a filesystem rather than using raw java.io.File which is harder to mock and unit test. By default the code displays a ZK screen to browse the inside of commons-vfs2-2.0.jar as though it were regular files and folders. Simply change the FILE_SYSTEM_URI uri in the ViewModel class to be file location like “file:///some/path/” to view a regular filesystem.

The zul page contains a tree and binds it’s model to vm.treeModel and it’s selectedItem event to the vm.pickedItem method:

<?xml version="1.0" encoding="UTF-8"?>
<zk>
    <window apply="org.zkoss.bind.BindComposer"
        viewModel="@id('vm') @init('org.github.simbo1905.zktreemvvm.CommonsVfs220ViewModel')">
        <tree model="@load(vm.treeModel)" selectedItem="@bind(vm.pickedItem)">
            <treecols>
                <treecol label="name" />
                <treecol label="index" />
            </treecols>
            <template name="model" var="node" status="s">
                <treeitem>
                    <treerow>
                        <treecell label="@bind(node) @converter('org.github.simbo1905.zktreemvvm.NodeConverter')" />
                        <treecell label="@bind(s.index)" />
                    </treerow>
                </treeitem>
            </template>
        </tree>
    </window>
</zk>

The @Converter does the friendly rendering of the FileObject data held in the tree model.

The actual ViewModel does not do much but hold the selectedItem event handler (which does nothing but log) and provides access to the TreeModel:

public TreeModel<FileObject> getTreeModel() {
    if (treeModel == null) {
        try {
            FileSystemManager fsManager = VFS.getManager();
            FileObject fo = fsManager.resolveFile( FILE_SYSTEM_URI );
            treeModel = new CachingVfsTreeModel(fo);
        } catch (FileSystemException e) {
            throw new IllegalArgumentException(String.format("Could not open VFS uri: %s",FILE_SYSTEM_URI),e);
        }
        }
    return treeModel;
}

The main work is in the VfsTreeModel class which extends AbstractTreeModel and defines the mandatory methods

public class VfsTreeModel extends AbstractTreeModel<FileObject> {

// __ snip __

@Override
public FileObject getChild(FileObject parent, int index) {
    log.info(String.format("%s getChild on %s with index %s", level(parent), innerName(parent), index));
    FileObject child = null;
    try {
        FileObject[] children = parent.getChildren();
        child = children[index];
    } catch (FileSystemException e) {
        throw new IllegalArgumentException(e);
    }
    return child;
}

@Override
public int getChildCount(FileObject node) {
    int childCount = 0;
    try {
        FileType type = node.getType();
        if( type == FileType.FOLDER ){
            childCount = node.getChildren().length;
        }
    } catch (FileSystemException e) {
        throw new IllegalArgumentException(e);
    }
    log.info(String.format("%s getChildCount on %s returning %s",level(node),innerName(node), childCount));
    return childCount;
}

@Override
public boolean isLeaf(FileObject node) {
    boolean isLeaf = false;
    try {
        FileType type = node.getType();
        isLeaf = (type == FileType.FILE );
    } catch (FileSystemException e) {
        throw new IllegalArgumentException(e);
    }
    log.info(String.format("%s isLeaf on %s returning %s", level(node),innerName(node), isLeaf));
    return isLeaf;
}

There was a recommendation in this bug tracker to override the getPath to prevent the framework making a lot of other calls to figure out that infomation:

http://tracker.zkoss.org/browse/ZK-1278

That method is implemented as a walk to the root:

@Override
public int[] getPath(FileObject node) {
    List<Integer> paths = new ArrayList<Integer>();
    try {
        FileObject parent = node.getParent();
        while (parent != null && parent.getType().equals(FileType.FOLDER)) {
            FileObject[] children = parent.getChildren();
            for( int index = 0; index < children.length; index++){
                FileObject c = children[index];
                if( node.equals(c)){
                    paths.add(index);
                    break;
                }
            }
            node = parent;
            parent = node.getParent();
        }
    } catch (FileSystemException e) {
        throw new IllegalArgumentException(e);
    }
    int[] p = new int[paths.size()];
    for( int index = 0; index < paths.size(); index++){
        p[index] = paths.get(p.length - 1 - index); // reverse
    }
    log.info(String.format("%s getPath on %s",level(node),innerName(node)));
    return p;
}

In the following Tree Model documentation and the “Huge Data” documentation it recommends caching:

http://books.zkoss.org/wiki/ZK_Developer%27s_Reference/MVC/Model/Tree_Model

http://books.zkoss.org/wiki/ZK%20Developer%27s%20Reference/Performance%20Tips/Listbox,%20Grid%20and%20Tree%20for%20Huge%20Data/Implement%20ListModel%20and%20TreeModel

So in the example code the ViewModel creates a caching subclass of the VfsViewModel. Refreshing the page would create fresh objects and let the cache be garbage collected which is probably good enough for this example.