|
/ Hathaway Weblog / Ape and Zope 3 |
Florent Guillaume has caught on to the big picture in Ape. The point of Ape is to allow you to make data storage decisions independently of application code. Ape is very flexible, while providing reasonable defaults for storing ZODB objects either in a relational database or in a filesystem.
Zope 2 clearly needs Ape. Standard ZODB provides a very productive development experience, but ZODB is opaque to anything but Python code, and that's a big concern for a lot of people. Ape resolves that concern by storing object state in an easily introspectable form, without requiring any changes to application code. Ape opens Zope and most Zope products to a wider audience.
However, Zope 3 may have a different answer to the opaque storage problem. The strong model/view separation in Zope 3 tends to move nearly all application functionality away from the model, leaving classes that define the model with only one responsibility: persistence. Therefore, it might be reasonable to create a different set of model classes for each type of persistence mechanism developers wish to support. For example:
def __init__(self, name, phone):
self.name = name
self.phone = phone
class Buddy_ZODB(Persistent, Buddy):
"""Buddy stored in ZODB"""
class Buddy_SQL(SQLObject, Buddy):
"""Buddy stored in a relational database"""
# define OR mapping here
Do Zope 3 developers want to multiply their classes this way? Personally, I don't want to write code like that. I doubt I would be effective at maintaining both branches of the code; for example, I might add an attribute to the Buddy class and forget to map the attribute to a SQL column in Buddy_SQL.
Perhaps I could write all my Zope 3 code using a relational database rather than ZODB. No, that's not really an option; ZODB makes me a better coder because it abstracts away the data storage problem so I can think about other things. Also, a lot of other people believe ZODB is good, and I want to use their code.
I conclude that Ape (or something very much like it) is still a good idea for Zope 3.
Comments
Any plans to start working on APE compatibility with Zope-2.8/ZODB-3.4? Alternatively do you have any plans to publish your APE 2.0 plan?
I'm currently working on porting APE to Zope-2.8/ZODB-3.4. If you are already working on this I'd be glad to help out. If not, perhaps your 2.0 plan would help me get a better grasp of the system that would help in my porting efforts.
Thanks.
