A while back, I was tasked with creating a versatile tree for OpenLaszlo that was extensible. It needed to have several features (available in different incarnations of the same base tree) for this one particular project:
- It had to support checkboxes for selection, independently of normal leaf selection.
- It needed to support visual tree lines.
- It needed to support drag-and-drop both internally (i.e. from one leaf to another) and externally (i.e. to drop targets outside of the tree).
- It needed to be easy to add icons to different nodes.
- It had to support large datasets. The “official” OpenLaszlo tree doesn’t support any form of lazy replication, so it was impractical.
I started with a version of opttree that was created by Adam Wolff (formerly of the Laszlo Foundation Classes and now of ShareGrove). In the meantime, that opttree got incorporated into OpenLaszlo, although it never made it into the official component set; it’s in the incubator. (Source for that opttree). In order to meet the above requirements, I needed to refactor the code somewhat to have a more reusable base class (sharedtreenode), from which I could create the various incarnations (checktreenode, dragtreenode, etc.). Mine never made it into the official OpenLaszlo distribution, although it has been widely used after it was informally released on the OpenLaszlo forums.
Anyway, that’s the background. Here’s one incarnation (checktree) in action:
I’ve finally updated this to run on OpenLaszlo 4.7; because it wasn’t part of the official distribution, it was never kept up-to-date. You can download the source for my opttree, complete with checktree, dragtree variants, as well as examples of how to add icons, and so forth. The test cases should give you a pretty good idea of how it’s used.
5 responses so far ↓
1 P T Withington // Jan 22, 2010 at 8:34 am
Gee, maybe you’d like to contribute this component back to OpenLaszlo? Of course that means you’d want to add some tests for it, so that it would be maintained…
2 antun // Jan 22, 2010 at 10:29 am
I would love to contribute this back to OpenLaszlo. The only reason that it’s not there already is that while I was working on this project, the original opttree - before I branched it - got there first. So when mine was ready to be contributed, it was too late.
What additional tests would need to be included other than the ones that are there already? Are you talking about lzunit tests?
3 Simon O'COnnor // Feb 15, 2010 at 7:20 pm
Ahh, good old opttree.
The version of the controller you have here is very inefficient however, it rebuilds the whole nodelist everytime ANY change occurs to the dataset, any attribute, (just rolling over the treenodes, and therefore changing a ‘hover’ attribute on the node for instance) causes a full rebuild.
This is very slow, especially if you have a number of opttrees in your app.
Changing the checkDocChange method to:
switch(chgpkg.what) {
case ‘appendChild’:
case ‘removeChild’:
case ‘openChange’:
case ‘dataSorted’:
this.rebuildList();
break;
default:
break;
}
And a couple of additions to fire the extra doc change types which you need to call from appropriate places in the optttree:
this.rootnode.ownerDocument.onDocumentChange.sendEvent({what:’dataSorted’,who:who});
this.rootnode.ownerDocument.onDocumentChange.sendEvent({what:’openChange’,who:who});
4 Simon O'Connor // Feb 15, 2010 at 7:21 pm
Also, I may have left out other changes I made to the opttree/controller to get that to work, I haven’t touched that code in some time… but you get the basic gist.
5 antun // Feb 16, 2010 at 4:10 pm
Thanks for the optimization suggestion Simon! I’m not sure what the procedure here is. Should I work to getting what I posted above into the OL project, and then you would be free to contribute your optimization improvements on top of that?
Leave a Comment