[Zope-CMF] CMF Tests: 9 OK
Summary of messages to the cmf-tests list. Period Tue May 27 11:00:00 2008 UTC to Wed May 28 11:00:00 2008 UTC. There were 9 messages: 9 from CMF Tests. Tests passed OK --- Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Tests Date: Tue May 27 21:40:50 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008885.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Tests Date: Tue May 27 21:42:20 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008886.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Tests Date: Tue May 27 21:43:51 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008887.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Tue May 27 21:45:21 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/00.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Tue May 27 21:46:51 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008889.html Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.4 : Linux From: CMF Tests Date: Tue May 27 21:48:21 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008890.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Tue May 27 21:49:51 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008891.html Subject: OK : CMF-trunk Zope-2.11 Python-2.4.4 : Linux From: CMF Tests Date: Tue May 27 21:51:21 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008892.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Tests Date: Tue May 27 21:52:52 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008893.html ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Working with Zope 3 skin layers
Charlie Clark wrote: What I think is still confusing me is: 1) I have created my dedicated skin 2) I have registered a view for that skin I assumed that by registering the view for the skin, the view would automatically use the right layer when called. Views don't "use" layers. You apply a skin layer to the request, and depending on whether the view was registered for this skin layer or any of the layers that are contained in that skin layer, the view will be found. The effect being much the same as a customised view in a CMF layer: higher up the chain takes precedence. Zope 3 layers and skins work exactly like that. But it seems that this is not the case: unless it is set otherwise Zope will use the default skin. Sure, but that's just like in the CMF where you tell the portal_skins tool which skin is the default. Is it possible to get individual views to use different skins without using ++skin++ in the URL? That doesn't make any sense to me and it's not how the CMF works either. In the CMF you may put different views in different skin layers (i.e. folders), but then you always combine them to a skin (in "Properties" page of the portal_skins tool where you enter a list of folders that make up the skin). For instance, you may have the following skin definition there: Default = custom something_else cmf_default This is very similar to Zope 3, except that we now have interfaces, e.g. ICMFDefaultSkin, ISomethingElse and IMyCustomLayer. You'd now register views for those layer interfaces (probably just for IMyCustomLayer) and then combine those layer interfaces in a skin interface, which is then given a name using the directive and then registered as the default skin: class IMySkin(ICustom, ISomethingElse, ICMFDefaultSkin): pass Regarding CMFDefault - all views are registered explicitly for ICMFDefaultSkin but I think this isn't necessary as this is configured as the default skin. No, it *is* necessary, because the default skin can always change. In fact, nearly every application (in the Zope 3 world) sets the default skin (otherwise you'd need those hideous ++skin++ things in all URLs). Also, by explicitly putting all views on the ICMFDefaultSkin layer, those views are only there if your skin interface inherits from ICMFDefaultSkin. Which means you can easily "switch off" those CMF views by not including ICMFDefaultSkin. For some people this is an important use case. Wouldn't that raise an error on startup if ICMFDefaultSkin isn't found? Uh, it's an interface... how can it not be found? Or how do you "not include" ICMFDefaultSkin? Using overrides? By having your skin interface not inherit from ICMFDefaultSkin, just like in the CMF where you would remove the cmf_default layer from the skin definition if you didn't want to have the views from cmf_default available. PS: in your book the appendix to ZCML browser:defaultSkin says "see browser:skin". This has been deprecated, I think. Ah, thank you! ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Working with Zope 3 skin layers
Am 28.05.2008 um 13:02 schrieb Philipp von Weitershausen: Views don't "use" layers. You apply a skin layer to the request, and depending on whether the view was registered for this skin layer or any of the layers that are contained in that skin layer, the view will be found. Thanks, that's the explanation I was missing - I hope I'm not the only one who doesn't quite understand what is adapting what when a view is called. 8-) The effect being much the same as a customised view in a CMF layer: higher up the chain takes precedence. Zope 3 layers and skins work exactly like that. But it seems that this is not the case: unless it is set otherwise Zope will use the default skin. Sure, but that's just like in the CMF where you tell the portal_skins tool which skin is the default. Is it possible to get individual views to use different skins without using ++skin++ in the URL? That doesn't make any sense to me and it's not how the CMF works either. In the CMF you may put different views in different skin layers (i.e. folders), but then you always combine them to a skin (in "Properties" page of the portal_skins tool where you enter a list of folders that make up the skin). For instance, you may have the following skin definition there: Default = custom something_else cmf_default This is very similar to Zope 3, except that we now have interfaces, e.g. ICMFDefaultSkin, ISomethingElse and IMyCustomLayer. You'd now register views for those layer interfaces (probably just for IMyCustomLayer) and then combine those layer interfaces in a skin interface, which is then given a name using the directive and then registered as the default skin: class IMySkin(ICustom, ISomethingElse, ICMFDefaultSkin): pass Okay, this is starting to make sense. Layers and skins are confusing especially as they are all just interfaces! :-O When does the skin name get used apart from in ++skin++ urls? Views are still registered to layers, ie. interfaces, aren't they? What I had been expecting to work, but which I think I now understand why it wouldn't, was the ability to add a layer for something like an "administration" layer which would call a version of standard_macros specific to that layer. I was hoping to be able to change this simply in ZCML rather than in the templates, ie. configure the views I want to use a different "skin". Instead, it seems, I need to write and register my own macros and change those templates that need to use them. Not sure whether this is entirely the right way to go about this, as opposed to using a viewlet to do it but as least I've got it to work. Regarding CMFDefault - all views are registered explicitly for ICMFDefaultSkin but I think this isn't necessary as this is configured as the default skin. No, it *is* necessary, because the default skin can always change. In fact, nearly every application (in the Zope 3 world) sets the default skin (otherwise you'd need those hideous ++skin++ things in all URLs). Also, by explicitly putting all views on the ICMFDefaultSkin layer, those views are only there if your skin interface inherits from ICMFDefaultSkin. Which means you can easily "switch off" those CMF views by not including ICMFDefaultSkin. For some people this is an important use case. Wouldn't that raise an error on startup if ICMFDefaultSkin isn't found? Uh, it's an interface... how can it not be found? I wasn't sure how you meant "not including ICMFDefaultSkin" and assumed you might mean leave out the configure.zcml from Products.CMFDefault.skin rather than not inheriting from it. Or how do you "not include" ICMFDefaultSkin? Using overrides? By having your skin interface not inherit from ICMFDefaultSkin, just like in the CMF where you would remove the cmf_default layer from the skin definition if you didn't want to have the views from cmf_default available. PS: in your book the appendix to ZCML browser:defaultSkin says "see browser:skin". This has been deprecated, I think. Ah, thank you! You're welcome. For the fourth edition, and I hope there will be one, it might be an idea to add a couple of paragraphs from above to clarify customisation by adding a layer, ie. where world_cookery inherits from Rotterdam and where it differs. 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 http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Working with Zope 3 skin layers
Charlie Clark wrote: Am 28.05.2008 um 13:02 schrieb Philipp von Weitershausen: Views don't "use" layers. You apply a skin layer to the request, and depending on whether the view was registered for this skin layer or any of the layers that are contained in that skin layer, the view will be found. Thanks, that's the explanation I was missing - I hope I'm not the only one who doesn't quite understand what is adapting what when a view is called. 8-) Um, this is explained in detail in my book. Views are always looked up like this: getMultiAdapter( (context, request), name="foo.html" ) (whitespace added for clarification.) So by applying marker interfaces to the request, we can change the output of that adaption. See pages 168-169 in my book. Is it possible to get individual views to use different skins without using ++skin++ in the URL? That doesn't make any sense to me and it's not how the CMF works either. In the CMF you may put different views in different skin layers (i.e. folders), but then you always combine them to a skin (in "Properties" page of the portal_skins tool where you enter a list of folders that make up the skin). For instance, you may have the following skin definition there: Default = custom something_else cmf_default This is very similar to Zope 3, except that we now have interfaces, e.g. ICMFDefaultSkin, ISomethingElse and IMyCustomLayer. You'd now register views for those layer interfaces (probably just for IMyCustomLayer) and then combine those layer interfaces in a skin interface, which is then given a name using the directive and then registered as the default skin: class IMySkin(ICustom, ISomethingElse, ICMFDefaultSkin): pass Okay, this is starting to make sense. Layers and skins are confusing especially as they are all just interfaces! That's what's so easy about them! :-O When does the skin name get used apart from in ++skin++ urls? Wherever you'd like to use it. Perhaps you'd like to show a list of available skins to the user so that s/he can choose one. Views are still registered to layers, ie. interfaces, aren't they? Yep. What I had been expecting to work, but which I think I now understand why it wouldn't, was the ability to add a layer for something like an "administration" layer which would call a version of standard_macros specific to that layer. I was hoping to be able to change this simply in ZCML rather than in the templates, ie. configure the views I want to use a different "skin". Instead, it seems, I need to write and register my own macros and change those templates that need to use them. Not sure whether this is entirely the right way to go about this, as opposed to using a viewlet to do it but as least I've got it to work. I'm not quite sure I'm following you here. Often skins mostly contain custom macros, meaning all views are registered for some default layer (e.g. IDefaultBrowserLayer) and they look up macros using context/@@standard_macros. Then it's up to the specific skin to provide a standard_macros view. This is the one that defines the look and feel of the site and therefore changes from skin to skin. This is exactly what my book explains and does (see Exapmles 10.3.2 and 30.3.3)! Forgive my bluntness, but it's hard to believe at this point you've read it... You're welcome. For the fourth edition, and I hope there will be one, it might be an idea to add a couple of paragraphs from above to clarify customisation by adding a layer, ie. where world_cookery inherits from Rotterdam and where it differs. The IWorldcookerySkin interface doesn't inherit from Rotterdam. And to be honest, I wouldn't know what else to write. I even have a "Flashback" box that compares Zope 3 style layers to CMF layers and skins on page 173. And what I've written in the two previous emails were mostly rephrased passages from my book anyway. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Working with Zope 3 skin layers
Am 28.05.2008 um 15:44 schrieb Philipp von Weitershausen: Thanks, that's the explanation I was missing - I hope I'm not the only one who doesn't quite understand what is adapting what when a view is called. 8-) Um, this is explained in detail in my book. Views are always looked up like this: getMultiAdapter( (context, request), name="foo.html" ) (whitespace added for clarification.) So by applying marker interfaces to the request, we can change the output of that adaption. See pages 168-169 in my book. I understand the theory. I know that views are adapters but as this is still something I'm not that familiar with and particularly as I don't write a lot of code using them, it's easy to forget what's exactly happening. class IMySkin(ICustom, ISomethingElse, ICMFDefaultSkin): pass Okay, this is starting to make sense. Layers and skins are confusing especially as they are all just interfaces! That's what's so easy about them! Agreed but it does make the naming interface/layer/skin entirely a matter of convention. Great once you're used to it. :-O When does the skin name get used apart from in ++skin++ urls? Wherever you'd like to use it. Perhaps you'd like to show a list of available skins to the user so that s/he can choose one. Okay - otherwise little relevance for programming? Views are still registered to layers, ie. interfaces, aren't they? Yep. What I had been expecting to work, but which I think I now understand why it wouldn't, was the ability to add a layer for something like an "administration" layer which would call a version of standard_macros specific to that layer. I was hoping to be able to change this simply in ZCML rather than in the templates, ie. configure the views I want to use a different "skin". Instead, it seems, I need to write and register my own macros and change those templates that need to use them. Not sure whether this is entirely the right way to go about this, as opposed to using a viewlet to do it but as least I've got it to work. I'm not quite sure I'm following you here. Often skins mostly contain custom macros, meaning all views are registered for some default layer (e.g. IDefaultBrowserLayer) and they look up macros using context/@@standard_macros. Then it's up to the specific skin to provide a standard_macros view. This is the one that defines the look and feel of the site and therefore changes from skin to skin. I understand this now. My current use case is This is exactly what my book explains and does (see Exapmles 10.3.2 and 30.3.3)! Forgive my bluntness, but it's hard to believe at this point you've read it... Reading is not necessarily understanding! This is no criticism of the book which, by the way, I think is exceptionally well written. But as with so many things, some things only click into place when you actually work with them and some things only make sense when you've mastered others. You're welcome. For the fourth edition, and I hope there will be one, it might be an idea to add a couple of paragraphs from above to clarify customisation by adding a layer, ie. where world_cookery inherits from Rotterdam and where it differs. The IWorldcookerySkin interface doesn't inherit from Rotterdam. And to be honest, I wouldn't know what else to write. I even have a "Flashback" box that compares Zope 3 style layers to CMF layers and skins on page 173. And what I've written in the two previous emails were mostly rephrased passages from my book anyway. Well, maybe it's an opportunity for me! ;-) Thank you very much for taking the time to explain this in greater detail. 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 http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] License file question
Just wondering: Now that we are splitting the CMF down into its constituent packages and people don't need to get the old-fashioned tarball, do we need to have a copy of the LICENSE.txt file in every package? And if yes, where would it go? It could go into each subpackage toplevel folder, where the setup.py resides, or down into the software folder where the other text files (README, CHANGES. etc) are located. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
