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

[Martin Aspeli]

Hi Yuppie,

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

Having explained this to a lot of different people with different levels 
of experience, I think "natural" is too strong a word for most people. 
The fact that browser views are adapters is an implementation detail 
that often give people an "aha!" type reaction when they really 
understand it. However, a lot of people will use browser views for a 
long time without really understanding adapters (if they ever do or care).

> And since add forms don't fulfill all the special criteria 
> for <browser:page />, we have to fall back to the more generic <adapter />.

Right. But there's a reason why <browser:page /> is "special". 
Logically, views and adapters are quite different things, and, of 
course, <browser:page /> does a lot more than just register an 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?

I'm not sure. Zope 2 doesn't really have a concept of security outside 
restricted python/traversal, so the translation form Zope 3 is always 
going to be a bit odd.

> 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 wonder why this is, though. There's probably a reason why the Five 
developers didn't want to extend the security stuff to the <adapter /> 
registration.

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

FWIW, I think this'll work:

     <adapter
         for="Products.CMFCore.interfaces.IFolderish
              zope.publisher.interfaces.browser.IBrowserRequest
              ..interfaces.IDexterityFTI"
         provides="zope.publisher.interfaces.browser.IBrowserView"
         factory=".add.DefaultAddView"
         />
     <class class=".add.DefaultAddView">
         <require
             permission="cmf.AddPortalContent"
             interface="zope.publisher.interfaces.browser.IBrowserView"
             />
     </class>

I don't much like it, though. :-/

I'd wager this is a lot closer to what people would expect:

   <cmf:addview
      for="Products.CMFCore.interfaces.IFolderish"
      fti="..interfaces.IDexterityFTI"
      class=".add.DefaultAddView"
      permission="cmf.AddPortalContent"
      />

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book