Thomas Lotze wrote:
> after having posted this to what I guess is the wrong list (all hail gmane
> group names...) and having received no answer, I'll repost it here:
> I noticed that zope.app.file.File does not inherit from
> zope.app.container.contained.Contained. This does not stop a file from,
> e.g., getting added to a folder (and the File type does appear in the
> ZMI add menu). It does, however, stop you from getting at the File's
> parent. Currently, File cannot be used as a proper content type, though it
> looks like it is supposed to be one.
> IMO File should inherit from Contained; am I wrong for some reason, or is
> this an issue that should be fixed? If the latter, I'd look into it.
Zope 3 doesn't require certain mix-in classes like Zope 2 does, so if
anything is needed at all here, it's definitely NOT a mix-in class.
Now, Zope 3 tries very hard not to impose anything on objects. That even
includes objects living inside an object hierarchy. For the containment
framework that means that objects can *choose* to provide IContained
themselves. In this case the containment framework puts a __parent__ and
__name__ on the object itself. If an object doesn't provide IContained
(and that's totally acceptable), the containment framework puts a
picklable containment proxy around it and stores that.
So, in short, even though File doesn't provide IContained, you can still
get a File's parent *if* that File object has been put in a folder and
you got it via the folder.
I explain this in more detail in my book, page 237f. I know you have a
Zope3-dev mailing list