Thanks for all the feedback to my previous mails. I hope I now have a
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
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
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