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

[Marc Lindahl]

OK, this is getting more tangled.  Is there any good documentation for 
coding practices regarding this stuff?

I found the definition of getPortalTypeName in DynamicTypes.py - does 
this mean that if you're making a portal type you should mix in 
DynamicType?  Because e.g. I don't think Archetypes is doing this (at 
least not that I find...)

The interface in portal_types.py does not have getPortalTypeName, but 
it does have getTypeInfo, which looks like if you pass an object and 
then access it's Id (e.g. here.portal_type.getTypeInfo(here).getId() ) 
then you'd get the same thing?


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