Thanks for all the feedback to my previous mails. I hope I now have a 
good solution.


Portal types are created TTW by configuring the types tool. If portal 
types are renamed or copied they still use the same content type and 
content factory. It should be possible to use the same add view as well.

This makes CMF add views special: They have to work with different 
portal types. That means:

- If we want simple URLs, we have to store the portal type name inside 
the add view name.

- We need customized traversal to look up the right view for each portal 
type and to pass the portal type to the view.

Proposed CMFDefault changes

1.) CMF add views adapt not only container and request, but also the 
type info object. This way the views can't be accessed directly and have 
self.fti available.

2.) By convention corresponding add view factories and content factories 
have the same name.

3.) A traversal hook looks up the type info based on the view name. And 
then returns the corresponding add form:
queryMultiAdapter((container, request, fti), name=fti.factory)

4.) For portal types without corresponding add form a fallback add form 
is added that just asks for the content ID.

5.) folder_factories becomes deprecated, add actions are shown in the 
main_template menu.

6.) An IPublishTraverse adapter is used for IFolderish objects. It tries 
to resolve names starting with '+' and falls back to 
DefaultPublishTraverse behavior if no add view is found. This way URLs 
like http://www.example.org/folder/+PortalType are supported.

Proposed CMFCore TypesTool changes

7.) listActions of the types tool returns add actions for *all* portal 

8.) If no add view expression is defined in the type info, a default add 
view URL is returned.

If there are no objections, I'll make the proposed changes on the trunk.

@ Jens: When exactly do you want to make the beta release?



Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Reply via email to