<html>
<head>
</head>
<body>
Hi Thomas,<br>
<br>
<blockquote type="cite" cite="mid:20030503075934.GA21782@planescape.com">
<blockquote type="cite">
<pre wrap="">Well...<br>My first idea is to drop the subclasses of the node. If that is too <br>little OOP,<br></pre>
</blockquote>
<pre wrap=""><!----><br>It is :)<br>I'm absolutely against creating realy big classes.</pre>
</blockquote>
Granted. Nevertheless I would like to ask how big such a class would become?
It would not have an openDialog. We would even take drawPert() and move it
into some kind of view object. (The node should not know how to display itself.
This should be done by some kind of formatter.)<br>
One might even think about moving the calculations to some other object,
as the calculating algorithms might have to be improved, and maybe the calculation
cannot be done on a local level, but only by an object that takes the whole
task tree into account? Then we would only have some attributes and the subnode
management. Would that really be too big?<br>
<blockquote type="cite" cite="mid:20030503075934.GA21782@planescape.com">
<pre wrap="">I'm wondering why I could not find a subproject class, what is the subproject<br>for class; and how is it different from Task.<br>In other words; aren't we making a whole lot of fuss about nothing?<br></pre>
</blockquote>
I think it is KPTProject, at least that is what KPTView::slotAddSubProject()
instantiates. The more I think about it, the more I come to the conclusion
that the difference betwenn task/subproject/milestone is more a difference
of formatting/displaying/view and has little to do with the data structure.
<blockquote type="cite" cite="mid:20030503075934.GA21782@planescape.com">
<blockquote type="cite">
<pre wrap="">And just in case we have an edit operation that would require to change <br>between task and project etc. we would replace the state object. The <br>node object would remain.<br></pre>
</blockquote>
<pre wrap=""><!----><br>Question;<br>how much is the 'switching' between taks and subproject view, and how much<br>data?<br>Should this solution be part of the datastructure? Or can we create a class<br>hierarchy for the (different) view's that solves the above problem?<br>The visiter pattern might be a better solution if its not really about the</pre>
</blockquote>
Absolutely.
<blockquote type="cite" cite="mid:20030503075934.GA21782@planescape.com">
<pre wrap="">Some alternatives and questions above.<br>Another alternative (I think we need at least one alternative :)<br>Implement a method 'replace' on the task that instanciates a new node of <br>the requested type and takes care of the copying (a clone method on each<br>node-extending-class) and replacing all references.</pre>
</blockquote>
<br>
Well... This is one way one could go, but it requires more than to add a
KPTNode::replace(), as every other object in the task tree that has a reference
to the node must be informed, and the views would have to be informed too.
I think there is a lot of potential for crashes in that. On the other hand,
we also have to keep all references in sync when we delete subtrees. So the
few lines of "delete node" that I committed yesterday, might not be sufficient
either.<br>
<br>
I will keep thinking,<br>
<br>
Heiko<br>
</body>
</html>