[Zope-CMF] Re: Re: Metatype() standard?
marc at bowery.com
Thu Mar 4 13:19:27 EST 2004
I did a search of the CMF 1.4.2 sources and did not find
getPortalType() anywhere, but I did find getPortalTypeName() - I'm
guessing that's what we've been talking about all along? I also found
this in HISTORY.txt (imagine that!!)
- Fixed the TypesTool so that TypeInformation's Title is
decorrelated from its Id (the old TypeInformation.Type() should
not be used anymore). The Id is what gets put in the "portal_type"
attribute of a content object, which one gets at using
somecontent.getPortalTypeName(). The Title is returned by
somecontent.Type(). "portal_type" is now indexed, and in most
cases should be used when doing catalog queries instead of "Type".
On Wednesday, March 3, 2004, at 07:13 PM, Tres Seaver wrote:
> Marc Lindahl wrote:
>> Hi Tres,
>> Thanks for the quick reply... important followups:
>> On Wednesday, March 3, 2004, at 03:38 PM, Tres Seaver wrote:
>>> Marc Lindahl wrote:
>>>> I'm crossposting this because I'm interested in feedback - is
>>>> Metatype() just a vestige of TypesTool or is it intended to be
>>>> standardized on? I was investigating this area and found that
>>>> Type() actually returns the TITLE of the type, not the meta_type,
>>>> unless there is no title, and also that Type() is supposed to be
>>>> depreciated. What's the real story? Anyone know?
>>> 'getPortalType()' should return the ID of the type object; 'Type'
>>> should return its title. What is deprecated is using 'Type' where
>>> what you really mean is 'getPortalType', as the two may not always
>>> be the same.
>> OK, so how does the id of the type object relate to meta_type as used
>> in products? Are those two meant to be matched/compared?
> Nope. The CMF *never* cares about meta_type, except as a fallback for
> objects which don't have 'portal_type'; this allows the same class
> (where meta_type is typically defined) to be used as the underlying
> implementation for multiple type objects. E.g., I can create a new
> MyDocument type object (in the types tool) which uses
> CMFDefault.Document as its underying implementation, but has different
> skins / workflow etc. associated with it, because the object gets
> 'portal_type' assigned by the type object, not the class.
>> Also, am I correct in stating that getPortalType returns an immutable
>> identification of the type, while Type/Title should be used only for
>> display (human readable) purposes?
>>> 'Metatype()' is a fossil;
>> OK... can someone notate that in the source?
>>> as far as I know, nothing in the CMF depends on it, except as an
>>> option to TypesTool.listContentTypes, where 'by_metatype' indicates
>>> that the returned types should be sorted by the result of >>> 'Metatype'.
>> ...and by chance, this is what CMFRating is doing. OK, so I guess
>> that means listContentTypes is depreciated too? So what should one
>> use, to get a list of types to compare to getPortalType()?
> You can still call the 'listContentTypes' method, just don't pass
> 'by_metatype=1' (the default is to sort by the ID of the type info
> Tres Seaver tseaver at zope.com
> Zope Corporation "Zope Dealers" http://www.zope.com
More information about the Zope-CMF