Hi,
in the Dolphin Smalltalk Companion Ted Brecht suggest that it's better to embed a hierarchy in the model itself and I couldn't agree more. However in the examples he gives, starting at page 213, he puts the hierarchy into the model and also additionally into a "Virtual Tree", in which every action to the model needs to be replicated, as only the "Virtual Tree" can be passed to a TreePresenter as the model. I don't know but to me that seems rather inelegant, and error prone. He merely indicates a third option, doing without the "Virtual Tree". Anybody care to indulge me how that could be done? Thanks Günther |
"Guenther Schmidt" <[hidden email]> wrote in message
news:[hidden email]... > Hi, > > in the Dolphin Smalltalk Companion Ted Brecht suggest that it's better to > embed a hierarchy in the model itself and I couldn't agree more. > > However in the examples he gives, starting at page 213, he puts the > hierarchy into the model and also additionally into a "Virtual Tree", in > which every action to the model needs to be replicated, as only the > "Virtual Tree" can be passed to a TreePresenter as the model. > > I don't know but to me that seems rather inelegant, and error prone. Why? VirtualTreeModel is simply an Adaptor which can be used to create a TreeModel "view" onto an arbitrary hierarchical data structure. This allows for the use of hierarchies that wouldn't be useable directly with TreePresenter without building a parallel TreeModel containing the same hierarchy of nodes. Such hierarchies might need the adapter because they are pre-existing (e.g. the class hierarchy), or because they are implemented externally (e.g. the file system), or because you want to design a new hierarchy without the constraint of representing it as a TreeModel. > > He merely indicates a third option, doing without the "Virtual Tree". > > Anybody care to indulge me how that could be done? 3 options: 1) Subclass TreeModel to implement your model. 2) Implement the <treeModel> protocol on your model so that it compatible with TreeModel without actually being a TreeModel. 3) Construct a parallel TreeModel to display your model when needed. This only really makes sense if the model is fairly static, or if a VirtualTreeModel would be too slow. Regards Blair |
Dear Blair,
thanks for the advice. Meanwhile I have made some progress on understanding what a VirtualTreeModel actually is. I basically add: a single model object asChildOf: nil to the virtual tree and then just forget about maintaining the virtual tree at all and instead add children directly to the root model object ie. to on of it's children. Ted Brecht duplicates this by adding to the virtual tree as well, something I'd like to avoid. Well according to him that should be sufficient also. However it doesn't automatically update the view, which might just be an implementation error of mine. Could you help me here? Thanks Günther Blair McGlashan wrote: > "Guenther Schmidt" <[hidden email]> wrote in message > news:[hidden email]... > >>Hi, >> >>in the Dolphin Smalltalk Companion Ted Brecht suggest that it's better to >>embed a hierarchy in the model itself and I couldn't agree more. >> >>However in the examples he gives, starting at page 213, he puts the >>hierarchy into the model and also additionally into a "Virtual Tree", in >>which every action to the model needs to be replicated, as only the >>"Virtual Tree" can be passed to a TreePresenter as the model. >> >>I don't know but to me that seems rather inelegant, and error prone. > > > Why? VirtualTreeModel is simply an Adaptor which can be used to create a > TreeModel "view" onto an arbitrary hierarchical data structure. > This allows for the use of hierarchies that wouldn't be useable directly > with TreePresenter without building a parallel TreeModel containing the same > hierarchy of nodes. Such hierarchies might need the adapter because they are > pre-existing (e.g. the class hierarchy), or because they are implemented > externally (e.g. the file system), or because you want to design a new > hierarchy without the constraint of representing it as a TreeModel. > > >>He merely indicates a third option, doing without the "Virtual Tree". >> >>Anybody care to indulge me how that could be done? > > > 3 options: > 1) Subclass TreeModel to implement your model. > 2) Implement the <treeModel> protocol on your model so that it compatible > with TreeModel without actually being a TreeModel. > 3) Construct a parallel TreeModel to display your model when needed. This > only really makes sense if the model is fairly static, or if a > VirtualTreeModel would be too slow. > > Regards > > Blair > > |
Guenther Schmidt wrote:
> However it doesn't automatically update the view, which might just be an > implementation error of mine. That's because there's nothing to tell the TreeView that the tree has changed. If you change any model then /something/ must tell the corresponding view(s) about the change. If you are using a TreeView then it expects to see certain specific events triggered off its Model. For instance #item:addedInParent:. If you don't generate those events (somehow) then it will not update as the tree changes. Now if you are using a VirtualTreeModel, then /you/ have to tell the virtual tree about any changes that you have made to the /real/ tree (the hierarchical arrangement of the objects in your real Model). It will then respond by triggering the events that a TreeView is expecting to see. The way you tell it about such changes is by calling methods like #add:asChildOf:. If you look at the implementation of that method, you'll see that it just triggers an event. You may think it's odd that you have to call a method like #add:asChildOf: in order to tell it about changes, rather than -- say -- #notifyChild:addedTo:. I think it's odd myself. However that is what its called, so that's what you have to use. It may /look/ like error-prone duplication, but it's really just a change notification. BTW, I don't think the choice of selector is /wrong/ -- it means that the user of the tree model is insulated from knowing whether the tree model is actually virtual or non-virtual, or maybe some kind of hybrid of the two. Still, it is definitely confusing when you first try to work out how Dolphin tree models work. -- chris (BTW, looking at the tree example in Ted book, there's some stuff about #beFinalizable which I recommend you just ignore. I think it must be an error that managed to get past the proof reading somehow.) |
Dear Chris,
tahnks for taking the time and laying this out to me. Now things start making a whole lot more sense. I have a procedural background (unfortunately) and eventhough I absolutely LOVE the dependency mechanism it is still a steep learning curve at least at the beginning. Tnanks Günther Chris Uppal wrote: > Guenther Schmidt wrote: > > >>However it doesn't automatically update the view, which might just be an >>implementation error of mine. > > > That's because there's nothing to tell the TreeView that the tree has changed. > > If you change any model then /something/ must tell the corresponding view(s) > about the change. If you are using a TreeView then it expects to see certain > specific events triggered off its Model. For instance #item:addedInParent:. > If you don't generate those events (somehow) then it will not update as the > tree changes. > > Now if you are using a VirtualTreeModel, then /you/ have to tell the virtual > tree about any changes that you have made to the /real/ tree (the hierarchical > arrangement of the objects in your real Model). It will then respond by > triggering the events that a TreeView is expecting to see. The way > you tell it about such changes is by calling methods like #add:asChildOf:. If > you look at the implementation of that method, you'll see that it just triggers > an event. > > You may think it's odd that you have to call a method like #add:asChildOf: in > order to tell it about changes, rather than -- say -- #notifyChild:addedTo:. > I think it's odd myself. However that is what its called, so that's what you > have to use. It may /look/ like error-prone duplication, but it's really just > a change notification. > > BTW, I don't think the choice of selector is /wrong/ -- it means that the user > of the tree model is insulated from knowing whether the tree model is actually > virtual or non-virtual, or maybe some kind of hybrid of the two. Still, it is > definitely confusing when you first try to work out how Dolphin tree models > work. > > -- chris > > (BTW, looking at the tree example in Ted book, there's some stuff about > #beFinalizable which I recommend you just ignore. I think it must be an error > that managed to get past the proof reading somehow.) > > > |
Free forum by Nabble | Edit this page |