I'm trying to code a very rudimentary GTD app for myself, not only to get organized, but to get better at coding and get better at Python. I'm having a bit of trouble with the classes however.
Here are the classes I have so far:
class Project:
def __init__(self, name, actions=[]):
self.name = name
self.actions = actions
def add(self, action):
self.actions.append(action)
class Action:
def __init__(self, do='', context=''):
self.do = do
self.context = context
Each project has actions to it, however I want to make it so that projects can also consist of other projects. Say daily I wanted to print out a list of everything. I'm having trouble coming up with how I would construct a list that looked like this
> Project A
> Actions for Project A
> Project B
> Sub project A
> Actions for Sub project A
> Sub project B
> Actions for Sub project B
> Sub project C
> Sub sub project A
> Actions for sub sub project A
> Sub sub project B
> Actions for sub sub project B
> Actions for Sub project C
> Actions for Project B
It's quite clear to me that recursion is going to be used. I'm struggling with whether to create another class called SubProject and subclass Project to it. Something there just makes my brain raise an exception.
I have been able to take projects and add them to the actions attribute in the Project class, however then I run into where MegaProject.actions.action.actions.action situations start popping up.
If anyone could help out with the class structures, it would be greatly appreciated!
You could create a subprojects member, similar to your actions list, and assign projects to it in a similar way. No subclassing of Project is necessary.
Even better, you may want to implement a composite pattern, where Projects are composites and Actions are leaves.
They key here is that the projects have the same interface as the actions (with the exception of the add/delete methods). This allows to to call methods on entire tree recursively. If you had a complex nested structure, you can call a method on the top level, and have it filter down to the bottom.
If you'd like a method to get a flat list of all leaf nodes in the tree (Actions) you can implement a method like this in the Project class.
I suggest you look at the composite pattern which can be applied to the "Project" class. If you make your structure correctly, you should be able to make action be a leaf of that tree, pretty much like you described in your example.
You could, for instance, do a Project class (abstract), a ProjectComposite class (concrete) and your action class as a leaf.
Have you evaluated existing GTD tools? I'd look at file formats used by existing GTD tools, esp. those that save to XML. That would give you an idea about which ways to organize this kind of data tend to work.
Structure ranges from rather simplistic (TaskPaper) to baroque (OmniFocus). Look around and learn what others did before you.