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

[Wichert Akkerman]

Previously Martin Aspeli wrote:
> 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.

It makes it more explicit that there is no real @@add 'thing' that
is traversed over.

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

The + naming for IAdding has always been a mystery to me. It feels very
out of place considering that it is just about traversing into a
add-view namespace.

Wichert.

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.