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 _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests