Forwarding my answer to the list since I (again) forgot to include it in the recipients initially.
---------- Forwarded message ---------- From: Bertrand Rousseau <[email protected]> Date: Tue, Jan 26, 2010 at 5:16 PM Subject: Re: [Gtg] Migrating Task to TreeNode To: Lionel Dricot <[email protected]> On Tue, Jan 26, 2010 at 4:45 PM, Lionel Dricot <[email protected]> wrote: > > Hello, > > In the process of my refactorization, I will have to mak Task() a > TreeNode. > > But I have some questions about Tree() and TreeNode() because that class > definitely needs some comments and some love. > > > > 1) Why are there multiple nodes with the same ID????? Why, when I do a > get_nodes(id), do I receive a list ? This seems very very very strange for > me. Please read my answer for #2 below before readig this. GtkTreeViews (whose support was the initial target of the Tree structure) don't support nodes with multiple parents, so it is required to create a tree where nodes have only one parent, and creating a node for each parent of an object. This technique enables to uniquify each object-parent relationship, creating then multiple nodes for one actual object. The get_nodes function gives all the uniquified nodes corresponding to a single object. This issue is hard to perceive for tags since they can have only one parent, but is relevant for multiple-parents objects like Tasks. > > 2) Why, when removing a node, should I provide both the ID and the node > itself ? What is the meaning of that ? Removing should take the ID only. First implementations of the tree were considered in order to provide a tree structure that would be object-agnostic. In other words, it would not be required for the object attached to a tree node to possess an id, that would be the business of the app that need access to certain objects in a structured way (here, a tree). That's why the Treenode is the object managing the ids. This code is also the consequence of the organic evolution of the GTG codebase towards the definition of GenericTreeModels for GtkTreeView, which were not mastered at the time of their development. Retrospectively, the refactoring you're considering now (which is the way to go, btw) can potentially make this previous approach obsolete and unappropriate. > 3) What is the self.ids of a TreeNode? I don't get it. It seems to contain > the IDs of children then why isn't self.children a dic ? Same answer. > 4) Why does add_child need both id and child_object. It should be the > object alone. (I guess the answer will be the same as for question 2) > Idem. > > Once I have answer to those questions, I will refactor a bit the Tree > class then make Task a TreeNode so the Trees are directly built in the > datastore and finally refactor the requester to take that into account (and > also to make it easier after reading Bryce's comments on it) > > > Lionel > > > > _______________________________________________ > Mailing list: https://launchpad.net/~gtg > Post to : [email protected] > Unsubscribe : https://launchpad.net/~gtg > More help : https://help.launchpad.net/ListHelp > -- Bertrand Rousseau -- Bertrand Rousseau _______________________________________________ Mailing list: https://launchpad.net/~gtg Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg More help : https://help.launchpad.net/ListHelp
