[Zope3-dev] Re: Last chance to comment on Simplify skinning
Benji York wrote: Gary Poster wrote: What if we still deprecated browser:layer but kept a redefined version of browser:skin? Then your zcml-- interface interface=.interfaces.ShanghaiSkin type=zope.publisher.interfaces.browser.IBrowserSkinType / utility component=.interfaces.ShanghaiSkin provides=zope.publisher.interfaces.browser.IBrowserSkinType name=ShanghaiSkin / could become browser:skin component=.interfaces.ShanghaiSkin name=ShanghaiSkin / Even though it's longer, I still like the interface/utility version. I think it really helps the developer understand what's going on and that it's not magic. The decreased brevity is of secondary concern to me. Helping the developer understand what's happening is laudable, but that's ultimately the job of documentation. When line count reduction is as drastic as the above, I really don't have a problem with having shortcut ZCML directives. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Last chance to comment on Simplify skinning
Fred Drake wrote: I would prefer not. We've used resourceDirectory to support things like webcams. The image(s) uploaded by the cams might not always be there, but the containing path is. It's nice not having Zope start Good point. If it was sugar for a set of resource directives, this could easily fail out on us, unless it was making 'resource' items all the time whenever the directory's contents changed. Right. In which case, another possibility would be to have a new directive that really is just sugar as I described. That would avoid backward compatibility problems and make the intention clear. +1 I was about to suggest the same but hadn't caught up with the thread. Either way, resource definitions are not quite the goal of my proposal so I'll leave it out of there. Perhaps Paul or whoever has the need for it would like to implement a resourcesFromDirectory directive... Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Last chance to comment on Simplify skinning
On Fri, Feb 17, 2006 at 01:17:22AM +0100, Philipp von Weitershausen wrote: Either way, resource definitions are not quite the goal of my proposal so I'll leave it out of there. Perhaps Paul or whoever has the need for it would like to implement a resourcesFromDirectory directive... I'll see if I can get to this during the pycon sprint :) -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Last chance to comment on Simplify skinning
On 2/16/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Either way, resource definitions are not quite the goal of my proposal so I'll leave it out of there. Perhaps Paul or whoever has the need for it would like to implement a resourcesFromDirectory directive... Right; this should definately be a separate proposal. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Last chance to comment on Simplify skinning
Dear Tonico, thanks for your input. In CMF things are very easy to understand, because a layer is simply a folder. I can explain that in five minutes to a template programmer. Why does the template programmer need to know about layers? Maybe this sounds a bit NAIVE, but would it be possible to make it like in CMF? The CMF approach is very limiting. The fact that a layer equals a physical location (a folder) led to every CMF-based product coming up with its own layer -- because there is no way to put stuff into existing layers, not even the default layer. Layers as they are in Zope 3 have stopped this senseless layer proliferation. I find Zope 3's approach much simpler and much easier to explain than the CMF's approach. In Zope 3 (especially with my proposed changes in place), a layer is simply a label (read: marker interface) on the request. When we now look up pages and resources (e.g. images), we take the request into account and therefore inevitably that label. We will only find pages and resources associated (read: registered) for this label. Good news is that any page or resource can be associated for this label, we just have to remember to do that in their ZCML directive. See, now I even explained this to a template programmer, though I don't think he'd care. Use case: Integrate an existing application into my Web site, e.g. a forum. 1. Create a folder for the customized forum skin $ mkdir forum-skin 2. Register this folder blah:skin-folder path=forum-skin ... / 3. Customize everything from original forum skin $ cd forum-skin $ cp $ORIGINAL_FORUM_SKIN/*.pt . $ vi * This is oversimplified, I know :) Yes. It's also limiting. Another note: when I see this I feel a cold shudder: browser:resource name=zope3logo.gif file=shanghailogo.gif type=.interfaces.ShanghaiSkin / Quite a lot of typing for one GIF!? Registering resources explicitly gives us the ability to easily override resources. That'll allow us to change logos, icons, etc. with just one ZCML directive. In fact, the ability to override is *the* foremost use case for registering stuff explicitly at all. If you want to save typing, you can have resource directories where you dump anything you want to be available as a resource. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Last chance to comment on Simplify skinning
Philipp von Weitershausen wrote: In CMF things are very easy to understand, because a layer is simply a folder. I can explain that in five minutes to a template programmer. Why does the template programmer need to know about layers? Because in CMF, if you want to customize or create a skin, you need to know about the so called layers. Maybe this sounds a bit NAIVE, but would it be possible to make it like in CMF? The CMF approach is very limiting. The fact that a layer equals a physical location (a folder) led to every CMF-based product coming up with its own layer -- because there is no way to put stuff into existing layers, not even the default layer. Layers as they are in Zope 3 have stopped this senseless layer proliferation. I find Zope 3's approach much simpler and much easier to explain than the CMF's approach. In Zope 3 (especially with my proposed changes in place), a layer is simply a label (read: marker interface) on the request. When we now look up pages and resources (e.g. images), we take the request into account and therefore inevitably that label. We will only find pages and resources associated (read: registered) for this label. Good news is that any page or resource can be associated for this label, we just have to remember to do that in their ZCML directive. See, now I even explained this to a template programmer, though I don't think he'd care. Maybe I mean something different. I just want a folder in which I can drop all the files I want to customize (I love to customize), without registering something. Is this a layer? You're right, I don't care :) Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Last chance to comment on Simplify skinning
Tonico Strasser wrote: In CMF things are very easy to understand, because a layer is simply a folder. I can explain that in five minutes to a template programmer. Why does the template programmer need to know about layers? Because in CMF, if you want to customize or create a skin, you need to know about the so called layers. But we aren't in the CMF :). Seriously, you are right about the fact that you need to know about layers when you want to work with skins. Let's just be clear on the actors' names: template programmer isn't necessarily the same as a skin customizer. A template author just writes a page template and isn't necessarily concerned how and where it is going to be registered. Most of the time, it is fine to register browser pages (incl. template-based ones) for the default layer. That is a huge difference to the CMF where everything lives in a very specific layer (which I find annoying and complicated) and that layer has to be registered in a skin (which most CMF product's Install.py will automatically do...). Now, the skin customizer might write some templates to actually perform some customization first, but his job description really is about setting up the layer(s) and registering one of them as a skin. For that you need to know about layers, yes. But not when you only want to author a template. Maybe this sounds a bit NAIVE, but would it be possible to make it like in CMF? The CMF approach is very limiting. The fact that a layer equals a physical location (a folder) led to every CMF-based product coming up with its own layer -- because there is no way to put stuff into existing layers, not even the default layer. Layers as they are in Zope 3 have stopped this senseless layer proliferation. I find Zope 3's approach much simpler and much easier to explain than the CMF's approach. In Zope 3 (especially with my proposed changes in place), a layer is simply a label (read: marker interface) on the request. When we now look up pages and resources (e.g. images), we take the request into account and therefore inevitably that label. We will only find pages and resources associated (read: registered) for this label. Good news is that any page or resource can be associated for this label, we just have to remember to do that in their ZCML directive. See, now I even explained this to a template programmer, though I don't think he'd care. Maybe I mean something different. I just want a folder in which I can drop all the files I want to customize (I love to customize), without registering something. That's not how it works in Zope 3, at least not right now and not by default. My proposal doesn't isn't addressing this. Shane has expressed an interesting idea that goes into the I just drop my stuff in here direction, but I'm frankly missing some important points in this idea yet. It might be interesting to develop it further, though. For now, however, we have to explicitly register everything. I consider that a good thing. Is this a layer? A layer is a marker interface on the request (Zope 3 definition). You're right, I don't care :) I think you don't care for the wrong reasons. You want your CMF experience duplicated. Perhaps you're not as bothered as I was with the CMF's limitations, but it sured annoyed me as hell having to create a new layer for every product I wrote for CMF. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Last chance to comment on Simplify skinning
Tonico Strasser wrote: Philipp von Weitershausen wrote: [snip] See, now I even explained this to a template programmer, though I don't think he'd care. Maybe I mean something different. I just want a folder in which I can drop all the files I want to customize (I love to customize), without registering something. Is this a layer? You're right, I don't care :) I know this is on a side track from the simplify skinning discussion, but: I think it'd be nice to have something that allowed you to register at least resources in a directory that still keeps intact the overriding capabilities that you'd have if you were to register a single resource. The current directive to register a directory of resources makes it easy to register a whole bunch of them in one go, but, unless I'm mistaken, makes it hard to override just *one* later (in another skin or override), as in fact the directory it registered directly. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Last chance to comment on Simplify skinning
On Wed, Feb 15, 2006 at 03:39:02PM +0100, Philipp von Weitershausen wrote: Maybe I mean something different. I just want a folder in which I can drop all the files I want to customize (I love to customize), without registering something. That's not how it works in Zope 3, at least not right now and not by default. My proposal doesn't isn't addressing this. Shane has expressed an interesting idea that goes into the I just drop my stuff in here direction, but I'm frankly missing some important points in this idea yet. It might be interesting to develop it further, though. For now, however, we have to explicitly register everything. I consider that a good thing. I think it's an important use case, though. In CMF, annoying and limited as it was, installing a skin was a one-time job. Adding or removing resources in that skin was trivial. I think you don't care for the wrong reasons. You want your CMF experience duplicated. Perhaps you're not as bothered as I was with the CMF's limitations, but it sured annoyed me as hell having to create a new layer for every product I wrote for CMF. Yes, I didn't like that either. Neither do I like the current system. I have to explicitly register every one of my skin's 35 resources? This is a significant burden. I do that a lot more often than I create new products. I think what we're angling for is some way to register everything in a certain directory as resources with one directive. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Last chance to comment on Simplify skinning
Paul Winkler wrote: I have to explicitly register every one of my skin's 35 resources? If the 35 resources (files) are in the same directory you can use the resource directory ZCML directive. Or am I missing something? -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Last chance to comment on Simplify skinning
On Wed, Feb 15, 2006 at 12:44:36PM -0500, Benji York wrote: Paul Winkler wrote: I have to explicitly register every one of my skin's 35 resources? If the 35 resources (files) are in the same directory you can use the resource directory ZCML directive. Or am I missing something? Only that I have the same question Martijn does: Can I then override one of those resources and keep the other 34? -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Last chance to comment on Simplify skinning
On 2/15/06, Paul Winkler [EMAIL PROTECTED] wrote: Only that I have the same question Martijn does: Can I then override one of those resources and keep the other 34? Perhaps the resourceDirectory directive should just be sugar for a set of resource directives, one for each file in the directory? That would allow individual overrides, and maintain the convenience. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Last chance to comment on Simplify skinning
On 2/15/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: I find Zope 3's approach much simpler and much easier to explain than the CMF's approach. In Zope 3 (especially with my proposed changes in place), a layer is simply a label (read: marker interface) on the request. When we now look up pages and resources (e.g. images), we take the request into account and therefore inevitably that label. We will only find pages and resources associated (read: registered) for this label. Good news is that any page or resource can be associated for this label, we just have to remember to do that in their ZCML directive. When you say with my proposed changes in place, I don't understand how that differs from what currently exists, or what can exist. We at Bottlerocket started serious Zope 3 work with Zope 3.1. We've been defining skins and layers as Interfaces since that time. I didn't understand it entirely at first, but when I was debugging some issues that arose with a fix to multi-adapter lookup that came in Zope 3.2, I understood it more, and now it makes a lot of sense to me. So coming from that world, I'm not entirely sure I understand how your proposal is really different, except for this: In your proposal, 'Skins' are just gone as a separate concept - yes? What is now treated as a Layer can also be treated directly as a skin, yes? Here's a situation from a recent application of mine. The comments and doc strings are verbatim. Notice that I leave a number of breadcrumbs behind about which is the skin and which is the layer:: # Layer class KBase(IBrowserRequest): The ``kbase.skin.KBase`` **Layer** # Skin class KnowledgeBase(KBase, CMS, IDefaultBrowserLayer): The Knowledge Base Skin. Uses the CMS layer, but **not** rotterdam. The Knowledge Base skin is very specialized and does not need as many generic features as the Content Management or default ZMI skins. The primary dependance on the CMS layer is to get its resources (javascript libraries, icons). I assign most things in my application to the KBase layer. The KnowledgeBase Skin builds from three layers. Very early versions of this app did a mix of layers and skins in the bases used for ``KnowledgeBase``, but the skin it used brought in too many views that I didn't want interfering with things accidentally, so I went with the ``CMS`` layer instead so I'd get things from our CMS layer, but not get *everything* that was chosen for the *Content Management* skin. Does that make sense? If I understand your proposal correctly, the Layer and Skin above would both basically be the same thing, right? The only thing that I guess really differentiates them right now (in my application) is how they're registered in ZCML. But they're each the same basic collection of interfaces. ``KBase`` is shallow and dedicated to the browser view/resource components in my application, ``KnowledgeBase`` is rich and pulls in components from others. The only thing that I don't understand right now is this concept of Interface Types. I don't have our Zope 3 book in front of me right now, so I'm not sure if it has anything helpful to say. But I'll just say that Interface Types have been an elusive concept for me, so far. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Last chance to comment on Simplify skinning
On 2/15/06, Jeff Shell [EMAIL PROTECTED] wrote: I would prefer not. We've used resourceDirectory to support things like webcams. The image(s) uploaded by the cams might not always be there, but the containing path is. It's nice not having Zope start Good point. If it was sugar for a set of resource directives, this could easily fail out on us, unless it was making 'resource' items all the time whenever the directory's contents changed. Right. In which case, another possibility would be to have a new directive that really is just sugar as I described. That would avoid backward compatibility problems and make the intention clear. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Last chance to comment on Simplify skinning
Jeff Shell wrote: I find Zope 3's approach much simpler and much easier to explain than the CMF's approach. In Zope 3 (especially with my proposed changes in place), a layer is simply a label (read: marker interface) on the request. When we now look up pages and resources (e.g. images), we take the request into account and therefore inevitably that label. We will only find pages and resources associated (read: registered) for this label. Good news is that any page or resource can be associated for this label, we just have to remember to do that in their ZCML directive. When you say with my proposed changes in place, I don't understand how that differs from what currently exists, or what can exist. We at Bottlerocket started serious Zope 3 work with Zope 3.1. We've been defining skins and layers as Interfaces since that time. I didn't understand it entirely at first, but when I was debugging some issues that arose with a fix to multi-adapter lookup that came in Zope 3.2, I understood it more, and now it makes a lot of sense to me. Cool! So coming from that world, I'm not entirely sure I understand how your proposal is really different, except for this: In your proposal, 'Skins' are just gone as a separate concept - yes? What is now treated as a Layer can also be treated directly as a skin, yes? Yes, you are right, that's basically the only change my proposal advocates (and some minor details around it). Here's a situation from a recent application of mine. The comments and doc strings are verbatim. Notice that I leave a number of breadcrumbs behind about which is the skin and which is the layer:: # Layer class KBase(IBrowserRequest): The ``kbase.skin.KBase`` **Layer** # Skin class KnowledgeBase(KBase, CMS, IDefaultBrowserLayer): The Knowledge Base Skin. Uses the CMS layer, but **not** rotterdam. The Knowledge Base skin is very specialized and does not need as many generic features as the Content Management or default ZMI skins. The primary dependance on the CMS layer is to get its resources (javascript libraries, icons). I assign most things in my application to the KBase layer. The KnowledgeBase Skin builds from three layers. Very early versions of this app did a mix of layers and skins in the bases used for ``KnowledgeBase``, but the skin it used brought in too many views that I didn't want interfering with things accidentally, so I went with the ``CMS`` layer instead so I'd get things from our CMS layer, but not get *everything* that was chosen for the *Content Management* skin. Does that make sense? If I understand your proposal correctly, the Layer and Skin above would both basically be the same thing, right? Not necessarily. You're free to create whichever layer hierarchy suits you best. At some point you can then say that a particular layer in that hierarchy (typically one that combines a lot of other layers) becomes known under a human-readable name. We then say it's a skin. My proposal gives you the freedom to promote any layer to a skin. That means you can also register views directly for a skin because it's just another layer. You won't have to create a layer and then a skin based on that layer... The only thing that I don't understand right now is this concept of Interface Types. I don't have our Zope 3 book in front of me right now, so I'm not sure if it has anything helpful to say. But I'll just say that Interface Types have been an elusive concept for me, so far. Interfaces mark objects. Like This is a recipe or This is attribute-annotatable. Interface types mark interfaces. Like This is not just some interface, it's an interface for content components or This is an interface we use as a skin. When you got my book in front of you, look up the beginning of Chapter 5. Interfaces extend z.i.Interface. Interface types extend z.i.i.IInterface (notice the double I) because they describe interfaces. Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
