[Zope-CMF] Calling context.setTitle() doesn't work when you're not a Manager

[Florent Guillaume]

>>>>How about adding DefaultDublinCoreImpl to SkinnedFolder's base classes ?
>>>>Would that pose a problem to anyone ?
>>>>I think it's the right thing here.
>>>
>>>
>>>Another option would be to add a new content class, ContentFolder, which
>>>mixed in the two items.  It might be a good candidate for the
>>>cataloguing stuff, as well.  I would actually prefer to be able to build
>>>a site entirely without PortalFolder, because I no longer find its
>>>"acquire index_html" behavior useful anywhere.
>>
>>That works too, and indeed is cleaner.
>>We're talking about CMFCore here, right ?
> 
> SkinnedFolder is in CMFDefault, n'est-ce pas?

I thought it would be best two have the three base classes in CMFCore: 
PortalContent, PortalFolder and PortalContentFolder. But now a realize 
that if we mixin DefaultDublinCoreImpl it would have to live in CMFDefault.

>>Would PortalContentFolder be a good name then, to follow the Portal 
>>prefix ? ContentFolder is ok too if you prefer.
> 
> In CMFDefault, I would just call it 'ContentFolder'.  Forward
> compatibility is a bit problematic here, because SkinnedFolder is likely
> already widely used for "content".  What if we added a new class,
> 'DynamicFolder', which derived from PortalFolder and had the __call__
> which is currently in SkinnedFolder?  SkinnedFolder would then derive
> from DynamicFolder, instead of from PortalFolder, while still mixing in
> CMFCatalogAware, but also adding DefaultDublinCoreImpl.

What's the problem with forward compat if we add a new class?

I would even propose making SkinnedFolder thus:

   class SkinnedFolder(CMFCatalogAware, PortalFolder,
                       PortalContent, DefaultDublinCoreImpl):

PortalContent would then give us also SearchableText.

Florent

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