ZK Developer's Reference/Performance Tips/Listbox, Grid and Tree for Huge Data/Implement ListModel and TreeModel

The default implementation of models, such as ListModelList and DefaultTreeModel assumes all data are available in the memory. It is not practical if a model has a lot of data. For huge data, it is suggested to implement your own model by loading and caching only a portion of data at a time.

To implement your own model, you could extend from AbstractListModel, AbstractGroupsModel and DefaultTreeModel as described in the Model section. To implement a model that supports sorting, you have to implement ListModelExt too. Each time an user requires sorting, ListModelExt.sort(Comparator, boolean) will be called and the implementation usually clears the cache and re-generate the SQL statement accordingly.

Here is some pseudo code:

public class FooListModel extends AbstractListModel implements ListModelExt {
    private Object[] _cache;
    private int _beginOffset;
    private String _orderBy;
    private boolean _ascending, _descending;

    public int getSize() {
        return /*SELECT COUNT(*) FROM ..
    }
    public Object getElementAt(int index) {
        if (_cache == null || index < _beginOffset || index >= _beginOffset + _cache.length) {
            loadToCache(index, 100); //SELECT ... FROM .... OFFSET index LIMIT 100
                //if _ascending || _descending, ORDER BY _orderBy ...
        }
        return _cache[index - _beginOffset];
    }
    public void sort(Comparator cmpr, boolean ascending) {
        _descending = !(_ascending = ascending);
        _orderBy = ((FieldComparator)cmpr).getRawOrderBy();
             //Here we assume sort="auto(fieldName)" is specified in ZUML, so cmpr is FieldComparator
             //On other hand, if you specifies your own comparator, such as sortAscending="${mycmpr}",
             //then, cmpr will the comparator you assigned
    }
}

For a real example, please refer to Small Talk: Handling huge data using ZK.

Version History

Version	Date	Content