[Zope-CMF] Types, meta_type, content_meta_type, etc...

[Tim Hoffman]

Just echoing what Shane has been saying (but in reverse ;-).

With some of the work we are doing we have a number of different types 
of Exhibitions objects
some are basically subclassed CMFTopic's and others a basic CMFContent 
with a property
which contains a list of UnqiueID's (which are catalogued).  To view 
this second object
it has the same basic access methods as used on CMFTopic are also used.

Both return lists of brains

One has a meta_type of DFTopicExhibition, the other has 
DFAuthoredExhibition.
Both have a Type of Exhibition. When people search for and use 
Exhibitions (as viewers)
they don't care what the specific meta_type is, they both look like 
exhibitions.

My problem is it seemed that it wasn't clear what meta_type and Type 
should have been
and when you define them through types tool vs basic Class definitions 
in a Product,
and in fact I think we have implemented it around the wrong way around, 
and so skinned folders
work one way and some other stuff is the other way (ie use of Type and 
meta_type)

Which probably measn I just didn't RTFM enough, but it has caused  quite 
a bit of confusion.

Tim





Shane Hathaway wrote:

> Chris Withers wrote:
>
>> Florent Guillaume wrote:
>>
>>> DublinCore's Type is presentation.
>>>
>>
>> ..no it's not. DublinCore's Type is exactly the same as the CMF 
>> content type. I
>> don't see any reason for them to be different ;-)
>
>
> I think I'm late in this thread, but I'm inclined to agree with 
> Florent.  I've learned from recent customer work that DC "Type" has a 
> meaning in people's minds that doesn't necessarily correspond with 
> CMF's definition.
>
> For this customer we built an "article" class and provided an 
> "article" TypeInformation object.  But when they searched for 
> articles, they wanted the "Type" to be "research report", "news 
> release", "column", etc.  As their business changed, they wanted to be 
> able to change the available types.  They would always choose the type 
> from a list, but it should be easy to change the type of an existing 
> object and changing an object's type shouldn't change its behavior.
>
> From an object-oriented perspective, that's all heresy.  But it's the 
> Real World. :-)  I think I've learned that Dublin Core is not designed 
> to be rigid or applied in a rigid way.
>
> CMF's ability to map objects to different application functionality 
> based on a simple, flexible attribute is very useful, of course.  But 
> it would appear that that capability should not be mixed with Dublin 
> Core, or at least not as deeply as it is now.
>
> For our customer we had to make up a new field, internally 
> representing the field under one name while displaying it as another.  
> It worked fine, but it's not ideal.
>
> Shane
>
>
>
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF@zope.org
> http://lists.zope.org/mailman/listinfo/zope-cmf
>
> See http://www.zope.org/Products/PTK/Tracker for bug reports and 
> feature requests