[Zope-CMF] New product and meta_type and portal_catalog

[Dieter Maurer]

Pascal Samuzeau writes:
 > ...
 > 1- Type and meta_type:                                                
 >                                                                       
 > I have tried to understand why there are those 2 attributes, and why  
 > we must use it. But still now I can't, because why not to let the     
 > meta_type as an attribute for an class's object as an usual attribute?
 > Even if it is to have a readable human attibutes.                     
CMF types have two levels:

  *  a (so called) content class, identified by "meta_type"

  *  a type description, identified by "portal_type" (with its
     human readable form "Type").

The content class defines properties, essential behaviour (methods).
The type description adds actions, workflow, policy (e.g. "dicussable").

Often, a single content class lies below different CMF types.

 > 2- CMFCatalogAware.                                                   
 >                                                                       
 > Sorry, but here it cannot be understand by my logical (or non logical)
 > brain.                                                                
 >                                                                       
 > What I want to do, as an user developper(not as a Zope's developper), 
 > is to create a class's object. If I need some methods, I rewrite them 
 > or write them only. But why should I care about the method of my      
 > parent's inherit in this case ?                                       
 >                                                                       
 > I mean, when I use of the ZMI, I want to add a new object's product. I
 > hope in this case that all will be fine. If my object must be         
 > catalogued, why the ZMI called manage_afterAdd of my proper object?   
 >                                                                       
 > If it does, something is wrong to my logical way, because it is not   
 > logical to try to catalogued an object with a method that I am able to
 > overwrite.                                                            
 >                                                                       
 > Or I must not be able to owerwrite this method, nor another method    
 > must be apply to catalog my object.                                   
 >                                                                       
 > Am I wrong to think that way ?                                        
At least it is not that clear.

     Some things (among them cataloguing) cannot be done in
     an object's constructor because they required context
     information about the place where the object resides
     inside the Zope Web-hierarchy (for cataloguing,
     the URL is essential).

     The Zope framework provides a hook for these things:
     "manage_afterAdd". It is called when the object
     was constructed and placed inside the Zope Web hierarchy.

     Objects that want to support cataloguing use this hook
     to call the respective cataloguing method.

     When you write a product and inherit from different classes,
     Python defines the name lookup as: instance, then class,
     then inherited classes from left to right.
     The first "manage_afterAdd" found in this way will be used.

     It is quite likely, that different inherited classes
     come with their own definition of "manage_afterAdd"
     (because they require different things after adding).
     In this case, your product is required to do the
     right thing: combine the various actions as necessary.

     In this case, the deriving class must know details about
     the requirements of the inherited classes and
     reconcile them. This is quite normal, at least with
     multiple inheritance.


Dieter