[Zope-CMF] CMF add views and <browser:page />

[yuppie]

Hi Martin!


Martin Aspeli wrote:
> yuppie wrote:
>>> How about a new <cmf:addview /> 
>>> directive that mimics <browser:page />, but registers the 
>>> (context,request,fti) adapter? I could probably put that together if 
>>> people think it's a good idea.
>> CMF add views are different because they are looked up by a special 
>> traverser, using the additional type info object. You have to be aware 
>> of that. No matter if you use <adapter /> or <cmf:addview />.
> 
> Sure.
> 
>> It is not obvious why you have to use explicit Zope 2 style security for 
>> add views and declarative Zope 3 style security for other views. But I'd 
>> rather like to see the 'permission' attribute of <adapter /> implemented 
>> for Zope 2 instead of a new <cmf:addview /> directive.
> 
> Mmmm... I'm not sure most people would find it natural to think about 
> the add form as an adapter like this.

Well. I find it natural to think about browser pages as a special kind 
of adapters. And since add forms don't fulfill all the special criteria 
for <browser:page />, we have to fall back to the more generic <adapter />.

> Also, Five's <browser:page /> does quite a lot of stuff that we now 
> can't have for CMF add views:
> 
>      o It allows a template to be registered
>      o It allows an attribute other than __call__ to be used to render 
> the view
>      o It sets up security on attributes, by interface or explicit list
>      o It sets up security on the view class itself

Sure. The question is: Do we really need these features for add views?

> I don't think the adapter permission attribute would be sufficient in 
> any case. In Zope 3, it's tied to a type of low-level security proxy 
> that doesn't really exist in Zope 2. The ClassSecurityInfo stuff only 
> affects restricted python/traversal, whereas Zope 3 security proxies are 
> applied everywhere.

AFAICS I didn't register the add views correctly. Provided interface 
should be IBrowserPage or IPageForm, not IBrowserView.

Given that, in the Zope 3 world <adapter />'s 'permission' attribute and 
<browser:page />'s 'permission' attribute would do the same: Creating a 
security checker that protects 'browserDefault', '__call__' and 
'publishTraverse' by the specified permission. Or am I missing something?

Currently this is not true for Zope 2. While Five implements Zope 2 
specific behavior for <browser:page />'s 'permission' attribute, the 
same attribute of <adapter /> is useless in Zope 2.

I can't see a fundamental problem in using the generic adapter directive 
for registering browser pages. I just see limited support for the 
adapter directive in Zope 2. As long as these issues are not resolved, I 
can live with Zope 2 security declarations in add views.


Cheers,

	Yuppie