[Zope-CMF] add Metadata element to existing types

Tim Hoffman timhoffman@cams.wa.gov.au
Fri, 01 Mar 2002 09:20:02 +0800


Hi Siegfried


Siegfried Stepke wrote:

>Thanks a lot Tim for your help!
>
No probs

>
>As a zope/cmf newbie that goes far beyond my current skills :-(
>
>I'm somewhat astonished to find features in the metadata tool (adding 
>elements) which are for no use and don't lead to the function one would 
>think and need...
>
Yeah, actually working out what the "correct" way of doing many things I 
think is the hardest
thing.

>
>I just spent a lot of time in learning and searching for information but 
>have to say that the learning curve is somewhat weird: simple solutions 
>are quite easy - but as soon as you need something specific you get to 
>limits: not because of the technology but the lack of proper informatio
>

>nor not so good implementation...
>
I believe this metatdata issue is design issue rather than a bug.
Reponses from other people about the inflexibility of the metadata design
revolve around the implementation of many CMF tools in CMFDefault.

I have been informed that CMFDefault implementations are really 
examples. The problem I have with this
statement is, there is so much in CMFDefault that is useable, and the 
work to rebuild all of the content
items with a different metadata model would be a huge job. So we have to 
muddle through.

See ya

Tim

>
>For the actual problem I wonder, if this meta data thing is a bug that 
>will be fixed in the near future (didn't find anything about it in the 
>tracking system) or if this is just like it is (for any or no reason)?
>
>regards,
>Siegfried
>
>>Siegfried Stepke wrote:
>>
>>>Hello,
>>>
>>>although I found lots of information regarding adding new CMF-Types
>>>
>>with 
>>
>>>their own properties I didn't find anything about adding a totally new
>>>
>>>element in the metadata to show up in the full_metadata_edit_form ...
>>>
>>>I succeeded in creating a new element in the portal_metadata tool; it
>>>
>>>shows up there and I can set its default or content-type-specific 
>>>settings. But I don't know what to do to let it show up in the
>>>
>>documents 
>>
>>>meta-data edit forms...
>>>
>>>Is this possible? (or are only the standard metadata elements
>>>
>>supported?)
>>
>>>Is this possible for the default portal-types?
>>>Do I have to create a new "custom/full_metadata_edit_form"?
>>> Which code would have to be integrated there for a subject-like
>>>
>>element?
>>
>>You need to patch defaultDublinCoreImpl with  new setter and getter
>>methods
>>and you need to modify the create and bind new __init__ and
>>_editMetadata,
>>and manage_editMetadata methods
>>
>>plus make a new full_metadata_edit_form
>>
>>I think one thing you need to consider is that these new elements that
>>you
>>are adding will be added to all CMF content types that have metadata.
>>
>>I have been doing this to extend the metadata to include AGLS
>>elements,
>>plus some additional ones of our own, which get coalesced into
>>Subject.
>>
>>>The goal is to integrate more metadata fields like
>>>
>>target_audience_level, 
>>
>>>client_category, etc. to be able to create nice topics specific to that
>>>
>>>data and even more...
>>>
>>
>>>I really searched a lot in the docs and archives and found a lot
>>>
>>similar 
>>
>>>questions but all answers just pointed to new types with properties -
>>>
>>not 
>>
>>>metadata.
>>>
>>I have attached the monkey patch we use. basically it is an init method
>>
>>in a product directory.
>>
>>You will note there are some other odd bit's in the code, like the 
>>generation of
>>a unique id for every piece of content that has metadata, which get's 
>>regenerated
>>if the object is cloned.
>>
>>
>>Regards
>>
>>Tim
>>
>>>thanks for any help!
>>>
>>>regards,
>>>siegfried
>>>
>