[Zope-CMF] listFolderContents

[Florent Guillaume]

On Sun, 2002-06-30 at 12:19, David (Hamish) Harvey wrote:
> > This stumped me too. The thing is, the Types Tool is a factory. With
> > only the Type Information, it has no way to get to an object to ask it
> > its meta_type, because that would mean constructing one first.  So the
> > reason content_meta_type is there, is that the Types Tool has no other
> > way to know a priori what the meta_type of constructed objects would
> > be.
> 
> So we're saying: content_meta_type just holds the value that the created 
> objects will have as meta_type (this feels crude, and is evidently not ever 
> so effective, given the amount of confusion it's causing :-). In that case 
> the equality of content_meta_type on the FTI and meta_type on the created 
> object should be checked at creation time.

Yes, it could probably be checked. If I do that I'd log a big error
instead of failing, though, you never know.

> Scenario:
> 
> I have two FTIs which both construct Documents. The final portal_type 
> attribute for objects created by each is different (just checked: it's set 
> to the id of the FTI). I want to allow Members to view and create one, only 
> Managers the other[1], say. With the current setup, and if I have set 
> content_meta_type "correctly" in the FTIs, then as Member I get back from 
> listContentTypes a list which *includes* "Document" because *a* type with 
> Document as it's base type is visible. So if any Document is visible given 
> my roles, all Documents are?
> 
> Construction is, I think, correctly controlled by the security settings on 
> the FTI, because the allowedContentTypes method on PortalFolder examines 
> the TIs individually.
> 
> The point here is that as time goes by and the requirements of my site 
> change slowly, I want to be able to turn on and off visibility and 
> creatability of objects represented by each FTI independently, whereas at 
> present I would need to modify all of the calls to listFolderContents to 
> update the contentFilter. I can't help but feel that as it stands, and 
> given your proposal for using contentFilter in CMF, the spec machinary 
> amounts to the vestigial remains of a Zope mechanism with little purpose in 
> CMF?

That was my conclusion too.

> > (Note that all that doesn't solve the problem that the code is using
> > ti.Type() all over the place, which is a human-readable string, where
> > it should use ti.getId(), which is what is set in the portal_type
> > attribute of created objects. But this is a separate concern, and
> > changing that would cause hairy backward-compatibility problems.)
> 
> In fact it makes it worse! ;-) It might be possible to help rather than 
> hinder here. It wouldn't disturb anything to add a "ContentType" or some 
> such parameter (named carefully :-) to the ContentFilter which checks 
> against the ids of the TIs? listContentTypes would also need to be able to 
> return ids (rather than the "title, or id if that isn't available) at the 
> moment). Then we could filter on id rather than the human-readable name.

I hope to fix all that soon.

> A couple of other thoughts
> 
> * The fact that TIs have a unique id, of course, means that 
> content_meta_type would be pretty redundant if it had the semantics I 
> thought it did (by which I mean to reinforce that I have been swayed by 
> your arguments).

Exactly.

> * Your proposed scheme for using contentFilter relies on _filteredItems 
> being called even with a None filter, so you'd need to remove the early 
> returns from contentIds, contentValues, and make sure that a filter of None 
> means something to _filteredItems.

Yes.

> * For what is the DynamicType machinery? Why would I want to change the 
> portal_type of an object at arbitrary times? And would I then be expected 
> to make sure that the corresponding TI was renamed to match (or at least 
> there existed a TI with id equal to my newly set portal_type)?

Good question. I don't know what DynamicType is for.

> * There would be a case (backward compatibility permitting :-) for having 
> two separate listContentTypes type methods - one which returns either 
> content_meta_type or id according to a parameter, the other that returns 
> human-readable names for use by skins.
> 
> * Blue sky: If the i18n machinery, couldn't the human readable title be 
> disposed of completely, and the id used as an i18n key?

Oh yes, that's what we want.

Bye,
Florent

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