Me again! Same project as before, if you're playing along at home.
The Everything Engine model (which I am blatantly copying in my project)
is that everything in the engine is a 'node,' and that every node can be
stored to and read from the database. Since this is the backend for a
website, minimizing hits on the database is a worthy goal. Thus, it is
paramount that reading in any given subclass of the base 'Node' class
take (optimally) one query. (A simple, yet fairly simple-minded design
-- and my first stab at the problem -- would be to have each subclass
read in its own data after calling its parent's -- or parents'! -- read
method(s). This has the disadvantage of cluttering a lot of code with
database queries and making it quite difficult to create new subclasses.)
Here's a rough sketch of what I'm doing at the moment. I've invested
enough time into it at this point that I've totally lost track of
whether it's a good idea, and I would please like someone to tell me.
Every node has certain attributes. In this outline, let's say these are
the node's unique id number, its title, and the id number of its owner.
class Node:
dbInfo = { 'title' : ['node', 'title', ""]
'owner_id' : ['node', 'owner_id', None] }
def __init__(self):
self.default()
def default(self):
self.node_id = None
for k, v in self.dbInfo.items():
setattr(self, k, v[2])
def read(self, db, node_id):
# construct a database query from the table/column info in
# dbInfo
def commit(self, db):
# write the current values to the db
def insert(self, db):
# insert a new node using the current values
def nuke(self, db):
# remove the node from the db, then:
self.default()
So, simple enough. (The real version has signifigantly more stuff going
on, as well as a permission system, but I have elided these for the sake
of clarity.) By doing that dance with dbInfo, I can easily subclass Node.
Say we want a new node that holds some text. We just need to add a new
attribute like so:
class Document(Node):
dbInfo = {}
dbInfo.update(Node.dbInfo)
dbInfo['content'] = ['docs', 'text', ""]
.... and that's it. That's the whole Document class. (Well, the real
version has a render method that takes the content, parses it in
interesting ways, and writes it to the client, but that's simple, too.)
The shortness of this class is why this strikes me as a good idea.
The other advantage is I can make use of multiple inheritance. First,
say we have a class that just holds a dictionary:
class DictNode(Node):
dbInfo = {}
dbInfo.update(Node.dbInfo)
dbInfo['stuff'] = ['dictnode', 'dict', {}]
(Assume a mechanism is provided to automatically pickle the dictionary,
which there is.)
Now say I want a nodetype that's just a document with a dictionary
attached. This is almost exactly how the User class is implemented: the
document holds the user's "homenode," which is just a brief bio or
whatever the user wants to put in there, and the dictionary holds the
user's settings. They snap together like Legos. It looks just like this:
class User(Document, DictNode):
dbInfo = {}
dbInfo.update(Document.dbInfo)
dbInfo.update(DictNode.dbInfo)
If the User class wanted its own attributes (say, a password), they
would just get added to the end.
This is my third stab at the problem (the first was mentioned above, the
second was basically the same as this but dbInfo was an instance
variable instead of a class variable which, uh, was sort of dumb).
Coming from C++, I'm still wrapping my brain around Python's
introspection abilties. Can I generalize this more? Am I missing some
idiom or language feature that would benefit me? Where's my time machine?
-Kirk McDonald
