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. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ 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