[Zope-CMF] [dev] 'add' actions and views - a proposal
Wichert Akkerman
wichert at wiggy.net
Sun Sep 21 10:59:49 EDT 2008
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?
Wichert.
--
Wichert Akkerman <wichert at wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
More information about the Zope-CMF
mailing list