[kplato] projects, subprojects and tasks

[Heiko Evermann]

Hi Thomas,

>>Well...
>>My first idea is to drop the subclasses of the node. If that is too 
>>little OOP,
>>
>
>It is :)
>I'm absolutely against creating realy big classes.
>
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.)
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?

>I'm wondering why I could not find a subproject class, what is the subproject
>for class; and how is it different from Task.
>In other words; aren't we making a whole lot of fuss about nothing?
>
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.

>>And just in case we have an edit operation that would require to change 
>>between task and project etc. we would replace the state object. The 
>>node object would remain.
>>
>
>Question;
>how much is the 'switching' between taks and subproject view, and how much
>data?
>Should this solution be part of the datastructure? Or can we create a class
>hierarchy for the (different) view's that solves the above problem?
>The visiter pattern might be a better solution if its not really about the
>
Absolutely. 

>Some alternatives and questions above.
>Another alternative (I think we need at least one alternative :)
>Implement a method 'replace' on the task that instanciates a new node of 
>the requested type and takes care of the copying (a clone method on each
>node-extending-class) and replacing all references.
>

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.

I will keep thinking,

Heiko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kplato/attachments/20030503/fdffaa9e/attachment.htm