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

[Martin Aspeli]

Wichert Akkerman wrote:
> Previously Martin Aspeli wrote:
>> 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.
> 
> The containerish thing is just a lookup-mechanism, which could be a very
> simple thing to figure out the right add view, which shouldn't be
> more than half a dozen lines of code. It feels like a perfect fit to
> me. 

I don't feel particularly strongly either way, so long as there's an 
actual namespace rather than a naming convention and we avoid an 
IPublishTraverse adapter for all IFolderish.

++add++PortalType is a bit uglier than /@@add/PortalType IMHO, but it's 
a transient URL so it doesn't really matter.

I think it's worth finding out why we have +/IAdding being a view and 
not a namespace traversal adapter, though. It feels that things like 
++skin++ or ++vh++ are a bit different to ++add++, though perhaps not.

Martin

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