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

[Martin Aspeli]

Wichert Akkerman wrote:
> Previously Martin Aspeli wrote:
>> Hi Yuppie,
>>
>>>>> 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).
>>> Yes. This causes more problems than it solves. I think I found a much 
>>> better solution:
>>>
>>> CMF add views are registered for a special layer called IAddViewLayer. 
>>> Like any other layer, IAddViewLayer extends IBrowserRequest. And it 
>>> defines an additional 'ti' attribute for the request.
>>>
>>> Like before views can't be accessed directly and have self.ti available. 
>>> (I now use 'ti' instead of 'fti' because we have other type info 
>>> implementations than FactoryTypeInformation.)
>> I'm not sure I like this much more. It involves adding a marker 
>> interface to the request conditionally during traversal. You'll possibly 
>> run into funny sequence dependent conditions if you want to customise 
>> the add view for a particular "theme" browser layer.
>>
>> My preference would be:
>>
>>   - Define an interface IFTIAwareView that has an 'fti' property
>>   - Define a traversal view (@@add) that does this kind of thing on 
>> traversal:
> 
> Why not a ++add++ traverser? Aren't traversed supposed to be used for
> that kind of thing? Or does a view gives us something here that a
> traverser doesn't?

Namespace traversal adapters are similar to IPublishTraverse solutions. 
The difference is that the namespace traversal adapter normally returns 
something "containerish" from which traversal continues. I think it's 
intended mostly as a "redirect" to a different traversal namespace, e.g. 
in the way that plone.app.portlets has namespaces for portlet managers.

IAdding is a normal view that itself implements IPublishTraverse, so 
that it can "eat" the next part of the traversal sub-path and react 
accordingly. I suggest we follow that convention (but call it something 
other than "+" since we have different semantics, and different aq 
wrapping).

Cheers,
Martin

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