I've run into an interaction between five.intid and
Products.CMFCore.DirectoryView a couple of times now.
DirectoryView stores instances of Persistent classes (like
FSPageTemplate) in a global registry and thus counts on those instances
never being added to a ZODB connection. When added to a ZODB
connection, the retrieval from global state could result in an instance
from a closed connection being de-ghosted raising a
ConnectionStateError. This seems wrong in that the object subclasses
Persistent but is being used in a way that doesn't allow it to be stored
in a ZODB. Why do the FSObject classes subclass Persistent?
For Persistent objects that have no connection yet, five.intid adds them
to the connection of the nearest parent object that already has a
connection. This is the same approach taken by zope.app.keyreference.
I previously committed a workaround to five.intid for a related
FSPythonScripts pickling error and I've extended that workaround to all
FSObjects for now. But I'd like to put the question of what the "right"
fix is before y'all. Whaddya think?
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests