[Zope-CMF] [dev] 'add' actions and views - a proposal

[Martin Aspeli]

yuppie wrote:
> Hi!
> 
> 
> Thanks for all the feedback to my previous mails. I hope I now have a 
> good solution.
> 
> 
> Context
> -------
> 
> 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.

This is quite interesting, and possibly necessary. However, it means 
that CMF add views are not just "views" and will need to be registered 
differently to other views (i.e. you can't just use <browser:page /> 
which also means that you won't get the Five security treatment etc).

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

+1

> 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)

Why do we need to *both* adapt the FTI and use the factory name as the 
view name?

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

+1

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

+0 (Plone will use actions in its 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.

-1

Or maybe -10 now that I think about it a bit more...

This is pretty invasive. It'd make it impossible to have another 
IPublishTraverse adapter for any IFolderish without either subclassing 
from the CMFDefault one or breaking all add forms.

Rather than invent a "pseudo" namespace with a naming convention, why 
not use a proper namespace, i.e. 
http://www.example.org/folder/@@add/PortalType ?

This is short, simple and allows alternative implementations if people 
want to use a different name (e.g. the @@add-deterity-content traverser 
in Dexterity), and does not require a clunky traverser for all 
IFolderish. Instead, you register the @@add view for IFolderish and have 
it implement IPublishTraverse as well.

> Proposed CMFCore TypesTool changes
> ----------------------------------
> 
> 7.) listActions of the types tool returns add actions for *all* portal 
> types.

+1 - this change is already done, right?

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

-0

Would it not be better to push this logic higher up, i.e. in the view 
code that's actually using the add views? The default for CMFCore is 
probably not going to be a suitable fallback for Plone, for example, 
which means we either need to customise/override or ensure that all 
types always have such an add action.

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

Apart from the traverser stuff, I think this sounds great. :)

Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book