[Zope-CMF] CMF Tests: 6 OK

2008-12-09 Thread CMF Tests Summarizer
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 /

2008-12-09 Thread yuppie
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

2008-12-09 Thread yuppie
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 /

2008-12-09 Thread Martin Aspeli
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 /

2008-12-09 Thread 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

___
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