[Zope-CMF] CMF add views and <browser:page />
Martin Aspeli
optilude at gmx.net
Tue Dec 9 08:34:23 EST 2008
Martin Aspeli wrote:
> 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"
> />
Meh - of course, I meant:
<cmf:addview
name="my.type"
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
More information about the Zope-CMF
mailing list