[Zope-CMF] [dev] 'add' actions and views - a proposal
optilude at gmx.net
Sun Sep 21 11:29:25 EDT 2008
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
>>> 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
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.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Zope-CMF