PDA

View Full Version : Tree implementation



cletus
1 Jul 2008, 7:03 PM
I'm new to Ext GWT, having done some previous work with My GWT.

I like the fact that GWT 1.5 has added generics and that Ext GWT is adding support for them.

That being said, I was shocked at the (imho unnecessary) complexity of the Tree implementation. This piece of code alone should set off alarm bells:

public interface TreeModel<T extends TreeModel> extends Model ...

which leads to things like:

BaseTreeModel<BaseTreeModel> ...

Its just overengineered and (again imho) wrong. A classic tree-like container with generics is implemented more typically with a composite pattern. The implementation could be greatly simplified by simply doing:

public interface Tree<T> {
T getItem();
Tree<T> getParent();
List<Tree<T>> getChildren();
}

rather than using "T extends TreeModel" polluting all your tree nodes by forcing them to implement TreeModel. The whole point of a container is to abstract relationships from that which is being stored, not to force the stored items to know about these external relationships.

Also, I'm sitting here looking at the implemtnation and seeing TreeBinders, TreeStores, etc and I have to scratch my head in wonder. Are trees really this hard? Speaking from some years of Swing experience, the answer is no, they're not. Even when you factor in capabilities to do lazy-loading and the like.

Or am I missing something here?

gslender
1 Jul 2008, 11:49 PM
I'd agree that the tree/table/combobox implementations at first glance are overly complex - the issue I think is more due to intended purpose and combined goals.

Eg. the tree implementation has bundled model and store functionality (which in itself is complicated by GWT multiple options for data loading).

I think there needs to be separation between Tree widget from a basic implementation perspective from the model/store/binder implementation.

A streamlined simple interface model that allows simple widget contsruction without complexity would be nice - then the additional interfaces/classes to provide store/model manipulation (kinda like what SWT has done for JFace viewers - the basic tree is simple, the model/viewer implementation is separate and extends the basic tree).

My 2 cents...

zaccret
3 Jul 2008, 5:56 AM
I'd agree that the tree/table/combobox implementations at first glance are overly complex+1

Are trees really this hard? Speaking from some years of Swing experience, the answer is no, they're not. Actually, it doesn't only affect trees but also table and combobox. It was already discussed here (but no answer yet) : http://extjs.com/forum/showthread.php?p=175480#post175480 (http://extjs.com/forum/showthread.php?t=36352). It is true that with Swing you have only one model for one tree, one model for one list, and not one model by item, but I don't know if it is the best practice and if it is suitable for gxt purposes.


The whole point of a container is to abstract relationships from that which is being stored, not to force the stored items to know about these external relationships.I think you raise a really good point and I agree. From a user point of view, it is not painless to have to implement ModelData (it was also partially discussed here http://extjs.com/forum/showthread.php?p=190270). Could not we really do without this interface ? Could not we replace the interface restriction by another ? StoreBinder could have no need for ModelData and look like this, for example :

public abstract class StoreBinder<S extends Store<M>, C extends Component, M>...{
//M does NOT extend ModelData
...
private ModelDisplayProvider<M> textProvider;
...
protected void update(TreeItem item, M model) {
if (item != null) {
setModel(item, model);
String txt = getTextValue(model);
if (txt == null && textProvider == null) {
txt = model.toString();
}

String icon = getIconValue(model);
String style = (styleProvider == null) ? null : styleProvider.getStringValue(model);

item.addStyleName(style);
item.setText(txt);
item.setIconStyle(icon);
}

}
...
protected String getTextValue(M model) {
//no more displayProperty
if (textProvider != null) {
return textProvider.getDisplayText(model);
}
return null;
}
...
}

public interface ModelDisplayProvider<M>{
public String getDisplayText(M model);
}
//do the same for icon (ModelIconProvider) and style (ModelStyleProvider)

zaccret
16 Jul 2008, 5:16 AM
Much better with that solution : http://extjs.com/blog/2008/07/14/preview-java-bean-support-with-ext-gwt/