[kplato] projects, subprojects and tasks
Thomas Zander
zander at planescape.com
Sat May 3 10:59:34 CEST 2003
> >>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
More information about the kplato
mailing list