[Zope-CMF] listFolderContents

[David (Hamish) Harvey]

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