Re: Contribution: ActiveTreeModel from TreeModel

Chris and Ian,

I must apologize.  I don't know how the forum got this post.  It was
late last night when I stopped working, but I'm pretty sure I selected
"save" instead of "post."  This post was going to take me a little while
to put together, and so I saved it as a draft.

Now that the cat's out of the bag, I should say that I'm going to be
making a contribution in the form of a package.  I'm done, and let this
be a testimonial of sorts to prospective customers of Dolphin and
Smalltalk.  I'm a complete neophyte to both, and yet I was able to
figure this out in just under two hours (I actually timed myself to get
a feel for my progress with the language and with Dolphin).  Writing the
source comments took about a third of that time.

What I've done is this:

1) subclassed TreeModel to create ActiveTreeModel;
2) subclassed TreeNode to create ActiveTreeNode;
3) added behavior to ActiveTreeNode such as #addChildNode:after:,
#addChildNode:before:, #moveChildNodeUp, #moveChildNodeUp:by:,
#atChildNode:put:, etc.
4) added corresponding behavior to ActiveTreeModel to wrap the behavior
of the ActiveTreeNode so that, in the same manner as that of TreeModel,
one is working with objects at the tree level, not nodes.  The objects
are in turn escalated to nodes using TreeModel's #getNodeFor:, and then
the appropriate ActiveTreeNode message is sent.

I have strived to follow the same format as TreeModel and to ensure that
usage of ActiveTreeModel will be non-breaking.  It seems that both of
you have addressed the dynamic sorting of newly-added nodes.
ActiveTreeModel will respect such a change since it uses #children to
obtain the underlying data structure.  So, if you've overridden
#children to return, say, a SortedCollection, then there would be no
problem (the only limitation is that the underlying data structure must
not be a fixed-size structure, such as Array).  Also, neither
ActiveTreeModel nor ActiveTreeNode has any supersends, and
ActiveTreeModel overrides only #nodeClass (to return ActiveTreeNode).
So if one has subclassed TreeModel, one should be able to refactor the
parent of ActiveTreeModel without any problems.

This morning I did some more reading in my Smalltalk books and spent
some time searching the Dolphin framework in order to make sure that my
two new classes adhere to the Smalltalk idiom.  I will be making some
idiomatic changes this afternoon (for example, I had
#replaceChildNode:with:, which should really be #atChildNode:put:, and
so forth).  Also, I want to increase the efficiency of
#moveChildNodeUp:by: and #moveChildNodeDown:by by explicitly targeting
the destination, as opposed to using #timesRepeat: to repeatedly call
#moveChildNodeUp and #moveChildNodeDown.  

I'll post the package this afternoon or early this evening; stern
criticisms will be welcome.

Again, I apologize.  You can imagine my dismay when I saw responses to a
post I thought I had simply saved as a draft :o

Cheers,

Eric







> -----Original Message-----
> From: Ian Bartholomew [mailto:[hidden email]]
> Posted At: Sunday, June 18, 2006 12:57 AM
> Posted To: comp.lang.smalltalk.dolphin
> Conversation: Contribution: ActiveTreeModel from TreeModel
> Subject: Re: Contribution: ActiveTreeModel from TreeModel
>
> >              but I would have thought (without trying) it should be
easy
> > enough to do in a normal tree.
>
> A quick play in a workspace (now that I've had my breakfast)
>
> "create a tree model and add some children"
> tm := TreeModel withRoots: #('root') searchPolicy: SearchPolicy
equality. the
> third character for extra excitement!"
> root := tm getNodeFor: 'root'.
> root children: (root children asSortedCollection: [:a :b | a object
third