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 _______________________________________________ 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