[Zope-CMF] What is the correct method for adding portal content programatically???

[Tim Hoffman]

Hi

I am struggling with the correct approach adding portal content 
programmatically


I have seen many examples in the "How to Automatically Add Objects at 
CMF member Creation Time" thread  and I have used similiar methods 
within a "Product" family where all of the objects are closely related.

However I think the method outlined in the above mentioned thread are
dangerous and architecturally the wrong approach.

I believe Portal types exist in CMF for a reason, ie to provide an abstract
interface to object types without having to explicitly include modules 
in your code

ie again in the above mentioned thread we see the following example

# Create Member's profile page.
>             # default_member_content ought to be configurable per
>             # instance of MembershipTool.
>             Document.addDocument( f
>                                 , 'profile_html'
>                                 , member_id+"'s Profile"
>                                 , member_id+"'s Profile Page"
>                                 , "structured-text"
>                                 , (default_member_profile % id)
>                                 )
>
> 

The Document.addDocument is the bit I don't like.

What you don't see is the statement at the top where they

from Products.CMFCore import Document 

which means you need to dig into class/module files
to identify the Products factory method in the class ie addDocument.
This doesn't seem to be the correct approach to me. I don't think this 
works for ZClasses,

I think for ZClasses you have to do something like 
content.manage_addProduct['Product name'].myFactoryMethod

I really want to have a consistent approach to adding all content.

The above approach also means you can't add new content types 
programtically that appear
after you have written your code, because you must know all the factory 
methods in your code.
The CMF Folder object actually calls invokeFactory which then goes 
through the portal_types
tool as outlined next.

I think the approach should instead be

getting a handle to the portal_types tool in an indirect manner.

tool_handle = getToolByName(context,'portal_types')

then use the portal_types tool public method 'constructContent' to
to create content which will use the factory method defined in 
portal_types be it
a ZClass or Product.

new_obj = tool_handle.constructContent('Document',container, id)

This seems to make more sense to me, it is then independant of class 
definitions etc...
everything is driven throught the portal_types tool, seems to be more 
portable etc..
ie someone else can create a new implementation of Document with a 
different factory method
and your code to create a Document won't break (as long as they haven't 
actually changed it's
functionality/public methods). New content types come along all you have 
to know is the
content_type which you can query portal_types for.

Magic, wonderful simple .....

Only problem is I can't get it to work. Ehaahaha!!!!!!!!

Am I completely barking mad, amd I missing something

DC guys can you comment?

TIA

Tim Hoffman