Re: [Zope-CMF] CMF add views and browser:page /
Am 12.12.2008 um 13:40 schrieb yuppie: 'browser:addform' and 'browser:editform' automatically generate forms based on a schema. The no longer supported 'browser:addview' directive was much closer to the directive Martin proposes. Since this registers an adapter that provides IBrowserPage, 'cmf:addpage' might be an alternative. I'd be happy with either cmf:addview or cmf:addpage. There's no way around the somewhat counterintuitive fact that the views are registered for the containing object type but as long as this is explained somewhere then anyone working with this should be okay. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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 Aspeli wrote: Providing customized solutions for specific use cases makes it easier to solve these use cases, but it also makes the framework more complex and less framework-ish. Then why do we have browser:page /? I guess primarily for historical reasons. And because zope.app is in some parts an application, not a framework. And because the 'template' attribute is sometimes a convenient shortcut. You could of course do: adapter for=.interfaces.IMyType Products.CMFDefault.interfaces.ICMFDefaultLayer provides=zope.interface.Interface name=myview factory=.myview.MyView / class class=.myview.MyView require permission=zope2.View allowed_interface=zope.publisher.interfaces.browser.IBrowserPage / /class The class/ hack is not necessary in Zope 3. This is much closer to browser:page/ and easier to read: adapter for=.interfaces.IMyType Products.CMFDefault.interfaces.ICMFDefaultLayer provides=zope.publisher.interfaces.browser.IBrowserPage name=myview factory=.myview.MyView permission=zope2.View / 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 /
Lennart Regebro wrote: On Tue, Dec 9, 2008 at 14:31, Martin Aspeli optilude-hi6y0cq0...@public.gmane.org wrote: 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 / Yes, although I'd probably call it addform. There is a browser:addform in Zope3, right? 'browser:addform' and 'browser:editform' automatically generate forms based on a schema. The no longer supported 'browser:addview' directive was much closer to the directive Martin proposes. Since this registers an adapter that provides IBrowserPage, 'cmf:addpage' might be an alternative. 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 /
On Tue, Dec 9, 2008 at 14:31, Martin Aspeli optil...@gmx.net wrote: 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 / Yes, although I'd probably call it addform. There is a browser:addform in Zope3, right? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ 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 Aspeli wrote: Martin Aspeli wrote: 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). Well. I guess it depends on your perspective. For Plone users adapters might be implementation details, for others they are important tools for solving many different problems. 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 AFAICS this should be IBrowserPage or IPageForm, not IBrowserView. / /class I don't much like it, though. :-/ I like it ;) This is not perfect. But better than using oldstyle Zope 2 security declarations. I'll change my checkins. Meh - of course, I meant: cmf:addview name=my.type for=Products.CMFCore.interfaces.IFolderish fti=..interfaces.IDexterityFTI class=.add.DefaultAddView permission=cmf.AddPortalContent / Providing customized solutions for specific use cases makes it easier to solve these use cases, but it also makes the framework more complex and less framework-ish. I can't see a need for the directive you propose. But if you also volunteer to maintain the additional code in the long run, I can live with it. 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 /
Hi Yuppie, 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). Well. I guess it depends on your perspective. For Plone users adapters might be implementation details, for others they are important tools for solving many different problems. Adapters are of course important tools. However, the fact that browser pages are named multi-adapters that provide Interface and adapt the context object and the request, normally via a marker interface called a layer that's applied to the request during traversal, is an implementation detail, and one that requires quite a lot of explanation and even then doesn't make a whole lot of sense unless you are quite familiar with Zope 3's brand of the adapter pattern. It took me 32 words to state that as completely and concisely as I could, without even explaining any of the concepts. The concept of a named multi-adapter is an order of magnitude more advanced than, say, page templates skin layers or the concept of having a class/template that's registered in an XML file. People who are not steeped in software design patterns can learn the latter quite quickly. They struggle with the former, Plone user or not. Providing customized solutions for specific use cases makes it easier to solve these use cases, but it also makes the framework more complex and less framework-ish. Then why do we have browser:page /? You could of course do: adapter for=.interfaces.IMyType Products.CMFDefault.interfaces.ICMFDefaultLayer provides=zope.interface.Interface name=myview factory=.myview.MyView / class class=.myview.MyView require permission=zope2.View allowed_interface=zope.publisher.interfaces.browser.IBrowserPage / /class I can't see a need for the directive you propose. But if you also volunteer to maintain the additional code in the long run, I can live with it. I can probably do that, but I'd like to know if others agree. I actually don't have an immediate need for it myself, since I've implemented the same thing for my specific use case using a martian grokker, but I suspect people would prefer an analogue to browser:page / rather than having to register their add views manually. If we want people to use add forms (in Plone we certainly do - premature object creation sucks), then we need to make it easy to do so. 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 /
Am 09.12.2008 um 14:34 schrieb Martin Aspeli: Meh - of course, I meant: cmf:addview name=my.type for=Products.CMFCore.interfaces.IFolderish fti=..interfaces.IDexterityFTI class=.add.DefaultAddView permission=cmf.AddPortalContent / Hiya, I agree that many people do not understand immediately that Views are Adapters. This is partly conceptual but also related to conventions in ZCML and elsewhere: it's very natural in English to contract view adapters to views and subscriber adapters to subscribers, etc. which is why we get ZCML-directives like subscriber and browser. I think it is correct to encourage developers to move to the ZCML approach for configuring security and as the new add views are CMF specific using a special CMF directive would make this clearer. A separate but related issue might be how we deal with CMFDefault: you seem to refer to it in much the same way I do as the basis for more work as it provides so much useful functionality out of the box but Jens, Tres and others never tire of pointing out that it is actually only a demonstration of what's possible. Should we think of breaking the formlib stuff out of CMFDefault? So that it can be used without CMFDefault? I don't know whether it should move to its own package or CMFCore. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] 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
[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] 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
