On Wed, Dec 05, 2007, Raphael Ritz wrote: >Bill Campbell wrote: > >[..] > >>Thanks Raphael. That works. >> > >Good to know.
Then I tried adding a PloneFormGen form which doesn't work. More stuff below. >>Should this then be the same as the ``portal_type'' in the class? >>I didn't get this from the Archetypes or ArchGenXML documentation. >> >>Does that mean that the import is not needed (asking before using >>the old learn-by-destroying methodology :-). >> > >As I never use ArchGenXML I have no idea what it needs or assumes >nor how you deal with it. That part of ArchGenXML I have figured out -- almost :-). >But I agree it can be somewhat confusing as long as you are missing >the big picture. > >First, there is Python ;-) >For Python (imports), the name of the class and the module(path) >matters. > >Next, there is Zope. >Zope adds the concept of a 'meta type' which may be identical to the >class name but doesn't need to be. In Plone you ususally don't deal >with the meta type unless you turn to the ZMI. There it is used all >over the place. > >Then there is CMF. >CMF adds the concept of a 'portal type'. You can have as many different >portal types based on the same Python class and Zope meta type as you >want. The portal type is used to assign content items - well, their >portal type - via having 'factory type information' (FTI) objects >with that very id in the types tool (the 'DynamicType' mixin class >implements this linkage). > >Finally, there is Archetypes, >which adds the 'archetype name' to the picture. This gets transfered >to the title of the corresponding FTI objects and is used, e.g., in >the user interface. My understanding of this, which may be wrong, is that this is a display only field. >Now, the confusion typically arises because often times these four >different things all have the same value (class name == meta type >== portal type == archetype name) so people usually don't need to >know or care and things just work. > >For the default content types today, however, the situation >is different, because Plone initially used the implementation >provided by CMFDefault and later switched to using the one >from ATContentTypes. As these are different implementations >of the same concept, their Python classes and (Zope) meta types >have to be different, while their portal types are of course >the same. This is why at the Python level you need to do things >like > >from Products.ATContentTypes.content.topic import ATTopic > (class name and path) > >while at FTI level, you need to use the more conceptual >portal type > > allowed_content_types = ['Topic', ...] > > >Maybe this clarifies things a bit? I thought I had it down until I tried adding a PloneFormGen form to allowed_content_types. I looked at the PloneFormGen/content/form.py file to see what it has defined, finding meta_type and portal_type bot the same, 'FormFolder' and archetype_name = 'Form Folder'. I added 'FormFolder' to allowed_content_types, but it doesn't appear after doing the appropriate incantations to restart Zope. This is true with or without an import line: from Products.PloneFormGen.content.form import FormFolder Now I am thoroughly confused :-). Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 You need only reflect that one of the best ways to get yourself a reputation as a dangerous citizen these days is to go about repeating the very phrases which our founding fathers used in the struggle for independence. -- Charles A. Beard _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
