[Zope-CMF] Re: Re: Metatype() standard?

[Marc Lindahl]

One final:
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".

-Marc


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?
>
> Yes.
>
>>>
>>> 'Metatype()' is a fossil;
>> OK... can someone notate that in the source?
>
> Done.
>
>>>  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 
> object).
>
> Tres.
> -- 
> ===============================================================
> Tres Seaver                                tseaver at zope.com
> Zope Corporation      "Zope Dealers"       http://www.zope.com