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? Ross _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests