[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
Re: [Zope-CMF] CMF add views and browser:page /
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 ___ 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 browser:page /
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 ___ 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 browser:page /
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 ___ 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