[Zope-CMF] listFolderContents
David (Hamish) Harvey
david.harvey@bristol.ac.uk
Sat, 29 Jun 2002 15:06:37 +0100
I've hammered my head against this code again, and the following present my
understanding of it. I disagree with Florent, but am prepared to be proven
wrong. That this issue causes confusion is hardly surprising given how much
controversy it can fuel among those who know zope/cmf best, for example:
http://lists.zope.org/pipermail/zope-cmf/2002-April/012247.html
--On Friday, June 28, 2002 22:38:54 +0000 Florent Guillaume <fg@nuxeo.com>
wrote:
> I now believe that the bug described in
> http://www.zope.org/Products/PTK/Tracker/483
> isn't a bug, but a case of poor understanding (maybe due to poor
> documentation) of the use of the contentValues, contentIds, contentItems
> and listFolderContents methods, and of the Type Information.
I disagree. At least, whether the bug is properly characterised is open to
debate, but the current behaviour is neither logical nor consistent.
> The methods have this interface:
> def contentIds(self, spec=None, filter=None)
> def contentValues(self, spec=None, filter=None)
> def contentItems(self, spec=None, filter=None)
> def listFolderContents(self, spec=None, contentFilter=None)
>
> The spec optional argument is a list of meta_types to filter on.
<aside>
The spec parameter passed to listFolderContents is currently discarded:
this *is* a bug, and I've submitted it as issue 520. I thought I'd done so
before but couldn't see it. I suspect that the issues under discussion have
been somewhat disguised by this bug.
</aside>
> Note that this filtering relies on the "Meta Type" (content_meta_type)
> parameter of a Type Information in the Types Tool to be correctly set,
> namely to be equal to the meta_type of the underlying object.
If to be "correctly set", content_meta_type==<meta_type of underlying
object> then content_meta_type and all the machinery that works with it is
redundant and shouldn't be there. This can't be true -- content_meta_type
is there for a reason and therefore, logically, one must be allowed to set
it to have a different value from the underlying meta_type.
> In the PortalType code, _morphSpec only deals with meta_types.
I presume you mean PortalFolder._morphSpec? Not true. _morphSpec accepts a
list of values, and assigns each of these in turn to a variable which it
confusingly calls meta_type. However, the values it retrieves from
types_tool.listContentTypes( by_metatype=1 )
are content_meta_types. The definition of listContentTypes uses
name = t.Metatype()
where t is a TypeInformation. TypeInformation.Metatype() returns
content_meta_type.
> The filter or contentFilter optional argument is a dictionnary with a
> key 'Type' (among others) and for value a string or a list representing
> the Types upon which filtering is desired.
>
> One could call for instance:
> listFolderContents(contentFilter={'Type': ['MyDocumentType',
> 'MyOtherType']})
This is orthogonal to spec, although similar effects can be achieved. I
would use this if in a *particular* context in a site I wanted to list only
objects with a particular portal_type. However if a number of
FactoryTypeInformations, each with the same underlying type and thus the
same underlying meta_type, I want to be able to use the View security
setting on those FTIs to control the visibility of instances created from
these FTIs across the *whole* site. I thus need functioning spec machinery
based on content_meta_type/portal_type.
The real killer, and the reason that at present content_meta_type must==
underlying meta_type, is that _morphSpec deals with content_meta_type,
while objectIds which is ultimately responsible for handling the spec
parameter expects it to contain meta_types. It would be preferable to the
current situation, probably, if _morphSpec was modified to deal with
meta_types, but at the same time this would be limiting and far from
perfect.
Cheers,
Hamish