[Zope-CMF] Re: Metatype() standard?
Marc Lindahl
marc at bowery.com
Thu Mar 4 20:10:25 EST 2004
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
More information about the Zope-CMF
mailing list