Implement ListModel and TreeModel"
m |
|||
Line 7: | Line 7: | ||
Here is some pseudo code: | Here is some pseudo code: | ||
+ | <source lang="java"> | ||
+ | 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(); | ||
+ | //Assume you specified auto(fieldName) in ZUML, so cmpr is FieldComparator | ||
+ | //If you specified comparator in ZUL, cmpr will be the comparator you assigned | ||
+ | } | ||
+ | } | ||
+ | </source> | ||
For a real example, please refer to [[Small Talks/2009/July/Handling huge data using ZK|Small Talk: Handling huge data using ZK]]. | For a real example, please refer to [[Small Talks/2009/July/Handling huge data using ZK|Small Talk: Handling huge data using ZK]]. | ||
Revision as of 01:30, 10 March 2011
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();
//Assume you specified auto(fieldName) in ZUML, so cmpr is FieldComparator
//If you specified comparator in ZUL, cmpr will be the comparator you assigned
}
}
For a real example, please refer to Small Talk: Handling huge data using ZK.
Version History
Version | Date | Content |
---|---|---|