Re: projects, subprojects and tasks

> >>Well, I have had a look at MS Project and at gnome/mrproject. In both 
> >>these programs a task becomes a subproject as soon as it gets some 
> >>children. Child tasks can be generated simply by indenting other tasks.
> >>
> >>I would also say that this is the behaviour that does not surprise the 
> >>user.
> >>
> >
> >Sounds fine then; but its too long ago that I looked at the code so I
> >don't know how to solve that; I suspect you have an idea?
> >
> 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.

> we can have a look at the state pattern from the "GOF".
> One nice link about it is 
> http://www002.upp.so-net.ne.jp/ys_oota/mdp/State/ :)
> But the link 
> http://exciton.cs.rice.edu/research/StatePat/seminar1/sld009.htm might 
> be easier to read.
You're a funny guy :-)


> In our case the node would keep a reference to a state object. These 
> state objects have the class hierarchy of Milestone, Project, Task, 
> Subproject.
> In all cases where this is neccessary, the node just forwards requests 
> to its state object.

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?

> 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
data..

> Let's think about these alternatives and let us look for more 
> alternatives, before we decide what to do.

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.

-- 
Thomas Zander