On Feb 13, 2006, at 10:33 PM, Shaun Cutts wrote:
I guess I must have asked too many questions at once :)
:-) and this is still a bit much for me.
a first pass of a container for external data and got it working on
of my collections.
I've included the (first pass of the) base DBContainer and DBContained
objects for criticism, and would be very grateful if anyone would like
to take a crack at it.
It looks like an interesting approach--more low-level than I would
have expected for a first cut, and *maybe* more low-level than
necessary. I wish I had more time to look at it.
Keep in mind, this is my first time working with the system, so I'm
I'm going about some things the wrong way. In particular, I already
1) Instead of have the contained object update the container, I should
rely on the event notification system.
Events are a tool for disconnected notification. calling a method on
an object is sending a message directly to the interested party. Not
everything should be an event. If a communication between two
components is a core aspect of your design, maybe direct method calls
are more appropriate.
2) Right now, the system works by translating objects "at the border"
(in IExternalContainer). Some translation is necessary, for
move from mx.DateTime to datetime.datetime, but still I think I should
somehow be making use of the "adaptor" interface.
If there's not an object to adapt then you have to start somewhere.
My glance at the code seemed to show that you were making a
reasonable choice. Another approach might be to have an abstract
"row" object that could represent any columns (a dict or something),
and named adapters registered for the row interface plus the name of
the generating table. I dunno, do what your app needs and refine it
as you discover what works.
3) Along these same lines, IDBContainer._containedType should
an interface (Object( schema = IDBContained ))
Note: is there a tutorial on writing containers anywhere I should have
read? I mainly figured this out by banging on it and fishing around in
the code. I'd love to figure out, for instance, what is really
with the traversals (with some interaction diagrams). I do think it
harder than it should have been. (But, then again, I think that about
Don't know of a tutorial. Sounds like you are interested in
traversal, though, which is different. Look at zope.app.traversing,
or zope.app.container.traversal. The headline is that there are two
kinds of traversal: URL path traversal and TALES path traversal.
They have different adapters.
BTW in my humble opinion, ILocation.__name__ is not well named. When I
first got an error referring to __name__ I thought it was expecting a
class object. And what happens when, for some strange reason, someone
wants to put a class in a container, and doesn't like its default
Not sure if that's a real use case for an ILocation.
That said, it's a reasonable POV to say that Zope shouldn't claim
__*__ names. But we do, so, well, yeah, we do. ;-)
Zope3-users mailing list