[Zope-CMF] CMF Tests: 4 OK, 2 Failed
Summary of messages to the cmf-tests list. Period Sun Dec 7 12:00:00 2008 UTC to Mon Dec 8 12:00:00 2008 UTC. There were 6 messages: 6 from CMF Tests. Test failures - Subject: FAILED (failures=3) : CMF-2.1 Zope-2.11 Python-2.4.5 : Linux From: CMF Tests Date: Sun Dec 7 20:51:39 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010508.html Subject: FAILED (failures=1) : CMF-trunk Zope-2.11 Python-2.4.5 : Linux From: CMF Tests Date: Sun Dec 7 20:54:39 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010510.html Tests passed OK --- Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.5 : Linux From: CMF Tests Date: Sun Dec 7 20:50:08 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010507.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.5 : Linux From: CMF Tests Date: Sun Dec 7 20:53:09 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010509.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.5 : Linux From: CMF Tests Date: Sun Dec 7 20:56:09 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010511.html Subject: OK : CMF-trunk Zope-trunk Python-2.5.2 : Linux From: CMF Tests Date: Sun Dec 7 20:57:39 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010512.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
[Zope-CMF] CMF add views and browser:page /
Hi, Thanks to yuppie, trunk now allows us to use the ++add++type traverser, which will look up an add view as an adapter on (context, request, fti) with name equal to fti.factory. This is good, but it does mean that those add views cannot be registered with a browser:page / directive. Unfortunately, Five's browser:page does quite a lot of stuff, from allowing a template to be specified, to setting up class and attribute level security, to supplying a docstring if required to allow publication. In CMFDefault, we have some base classes (tied to formlib) and we do manual security with a ClassSecurityInfo and InitializeClass(). This feels like a step backwards to me, at least in Plone, where we encourage people to use browser views with declarative (ZCML) security. It's difficult to explain that add forms are special so that they need to have manual security, explicit docstrings (for better or for worse), and be registered as an adapter /, not a browser:page /. Did we envisage a solution to this? 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. 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 Martin! Martin Aspeli wrote: [...] In CMFDefault, we have some base classes (tied to formlib) and we do manual security with a ClassSecurityInfo and InitializeClass(). This feels like a step backwards to me, at least in Plone, where we encourage people to use browser views with declarative (ZCML) security. It's difficult to explain that add forms are special so that they need to have manual security, explicit docstrings (for better or for worse), and be registered as an adapter /, not a browser:page /. Did we envisage a solution to this? No. 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 /. 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. 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
Hi Martin! 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. 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. 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
yuppie wrote: Hi Martin! 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. 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 /
yuppie wrote: In CMFDefault, we have some base classes (tied to formlib) and we do manual security with a ClassSecurityInfo and InitializeClass(). This feels like a step backwards to me, at least in Plone, where we encourage people to use browser views with declarative (ZCML) security. It's difficult to explain that add forms are special so that they need to have manual security, explicit docstrings (for better or for worse), and be registered as an adapter /, not a browser:page /. Did we envisage a solution to this? No. 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. 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 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. 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
