Possible solution to Re: [Zope-CMF] How to list objects of custom type and not of their base type?

[Florent Guillaume]

David (Hamish) Harvey <david.harvey@bristol.ac.uk> wrote:
> I've created a mini-product which hotfixes PortalFolder and DynamicType to 
> get round this. I'd appreciate comments on bugs, style, and reasons why it 
> can't be done like this. It appears to me to work, but I haven't given any 
> consideration to possible use cases in which this hideously breaks other 
> things.
> 
> http://wemrc10.wemrc.bris.ac.uk/zope.html

Well your fix is a bit heavy-handed :-) as you make ObjectManager code
know about portal_type which is a CMF concept.


> After all that, we can modify objectIds to check for a portal_type, and if 
> it's available compare that with spec, otherwise use meta_type.

Another bit of knowledge in ObjectManager that shouldn't be there...


In the bug report I suggest this:

  One more complicated solution is to derive the needed meta_type's for
  the portal_type's in the spec, call objectValues with the restricted
  list of meta_type's, then do the filtering above on this limited set of
  objects.

It's not as fast as your fix, but it's the cleaner I can manage (by
handwaving) until Zope 3 :-)



> One twist - it seems that for this to work, _morphSpec has to call 
> listContentTypes with by_metatype=0. This I fear might have implications.

Well yes, by_metatype=0 means you're really filtering on the customized
Title of the type (defaulting to the Metatype), not the Metatype.

> Note that this relies on the fix being in place before any items are 
> "_setObject"ed on a PortalFolder. To get round this, there's an external 
> method in the Extensions dir which will remove and re-add each object to 
> the directory using _setObject.

Why not directly go patch _objects ?

> It needs to be called in turn from a python script which passes it context. 
> Is there any way for an external method to obtain the context in which it 
> is called? I haven't worked this out.

Give it a first argument of self, it will be the context. Ok, call it
"context" then, it's not a real OO self.

> > In my sites I use a customized folder listing because of this, one that
> > doesn't call listFolderContents. With your example I'd call
> > objectValues('Document') and then filter by hand on portal_type.
> 
> That would have worked, and might have fewer side effects that what I've 
> done. It would have involved modifying all the plone templates to use it 
> though, and then keeping them in sync.

I hope Plone doesn't call objectValues, because it's not CMFish enough
so could explain some bugs. OTOH seeing that listFolderContents may be
unusable, it's understandable.

Florent


-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg@nuxeo.com