Re: [Zope-CMF] CMF add views and
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 implemented for Zope 2 instead of a new 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 , we have to fall back to the more generic . > > Right. But there's a reason why is "special". > Logically, views and adapters are quite different things, and, of > course, does a lot more than just register an adapter. > >>> Also, Five's 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 's 'permission' attribute and >> '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 's 'permission' attribute, the >> same attribute of 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 > 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: > >for="Products.CMFCore.interfaces.IFolderish > zope.publisher.interfaces.browser.IBrowserRequest > ..interfaces.IDexterityFTI" > provides="zope.publisher.interfaces.browser.IBrowserView" > factory=".add.DefaultAddView" > /> > >permission="cmf.AddPortalContent" > interface="zope.publisher.interfaces.browser.IBrowserView" > /> > > > I don't much like it, though. :-/ > > I'd wager this is a lot closer to what people would expect: > > for="Products.CMFCore.interfaces.IFolderish" > fti="..interfaces.IDexterityFTI" > class=".add.DefaultAddView" > permission="cmf.AddPortalContent" > /> Meh - of course, I meant: Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF add views and
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 implemented >>> for Zope 2 instead of a new 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 , we have to fall back to the more generic . Right. But there's a reason why is "special". Logically, views and adapters are quite different things, and, of course, does a lot more than just register an adapter. >> Also, Five's 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 's 'permission' attribute and > '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 's 'permission' attribute, the > same attribute of 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 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: I don't much like it, though. :-/ I'd wager this is a lot closer to what people would expect: Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Customising types with add views
Martin Aspeli wrote: > yuppie wrote: >> Martin Aspeli wrote: >>> [...] >>> >>> Let's consider a type Alpha that has a custom add form registered as >>> such a (context, request, fti) adapter with name "Alpha". fti.factory is >>> "Alpha", and there's a corresponding IFactory utility (with name "Alpha"). >>> >>> Now, let's say I want to create a new type Beta (e.g. by copying the FTI >>> object TTW), based on Alpha. I want this to use Alpha's add form, but >>> construct objects with portal_type Beta. >>> >>> Is this possible? If I set Beta's fti.factory to be something other than >>> "Alpha", then it won't find the add view, but if fti.factory is "Alpha" >>> then the objects constructed will use Alpha's factory. >> You should be able to register the same add view twice. One registration >> for the name "Alpha" and one for the name "Beta". > > Sure. I was thinking more about the case of customising by copying the > FTI TTW. > >>> I can't quite decide whether this is a problem in real life or not, >>> although it does seem a bit strange that the add view adapter name and >>> the factory utility name have to be the same. >>> >>> Would it make sense to decouple these, e.g. with a new "add_view_name" >>> property? >> If people really have that problem we can decouple this later. For now I >> can't see a need. > > I suspect it's YAGNI since the add view calls _setPortalTypeName() on > the newly created instance as well, so the resulting object will have > type Beta, not type Alpha. Oops! I just realized that I didn't read your example correctly. I thought you would *want* to set Beta's fti.factory to something different. As you noticed, using the same factory *and* add view for different portal types is supported. In fact that's the reason why we adapt the type info and can't use normal browser pages. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF add views and
Hi Martin! Martin Aspeli wrote: > yuppie wrote: >>> How about a new >>> directive that mimics , 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 or . > > 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 implemented >> for Zope 2 instead of a new 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 , we have to fall back to the more generic . > Also, Five's 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 's 'permission' attribute and '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 's 'permission' attribute, the same attribute of 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 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] CMF Tests: 6 OK
Summary of messages to the cmf-tests list. Period Mon Dec 8 12:00:00 2008 UTC to Tue Dec 9 12:00:00 2008 UTC. There were 6 messages: 6 from CMF Tests. Tests passed OK --- Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.5 : Linux From: CMF Tests Date: Mon Dec 8 20:48:44 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010513.html Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.5 : Linux From: CMF Tests Date: Mon Dec 8 20:50:14 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010514.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.5 : Linux From: CMF Tests Date: Mon Dec 8 20:51:44 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010515.html Subject: OK : CMF-trunk Zope-2.11 Python-2.4.5 : Linux From: CMF Tests Date: Mon Dec 8 20:53:15 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010516.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.5 : Linux From: CMF Tests Date: Mon Dec 8 20:54:45 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010517.html Subject: OK : CMF-trunk Zope-trunk Python-2.5.2 : Linux From: CMF Tests Date: Mon Dec 8 20:56:15 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010518.html ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
