Re: [Zope3-dev] RFC: Simplify Skinning Redux
>>No, we just make the registration of layers optional. If you want layers >>to be registered (and marked with an ILayerType marker) for whatever >>reason, it's your choice. The framework shouldn't make you like it does >>now. > > This will definitely backfire. Let's say I want to extend the wiki views > using > some TTW development. But the wiki package does not register the layer, then > the TTW developer is cut off. > > Note that I am not saying that the *framework* should require this, but it > should be at least a strong convention and people should do this registration > all the time. I disagree. The wiki package either supports the ZMI or it does not do. If it supports the ZMI, then it will register its layers. If it does not, then it won't. I would encourage people to register their layers with the ZMI, and to do things that couple their products to the ZMI, only when they make a decision that the ZMI is relevant to their stuff. If they decide that the ZMI is not relevant to their goals, they should stay well away from it. Let's say that the wiki system authors decide that the ZMI is out of scope for them. Someone else can come along and produce a wiki-in-zmi product that depends on the ZMI and on the original wiki. This is great, because it keeps the plain wiki produdct simpler and more approachable, and it keeps the dependency on the ZMI clear. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
>>I understand from this discussion that registering layers is needed only >>for certain ZMI things, to be implemented later on. So, I guess the >>ZCML will be implemented later on, or not implemented later on. In >>either case, later on. > > I disagree. The layers are registered now. You rip them out now, just so I > have to add them later again? That sounds dubious to me. Earlier, you were saying that you didn't see a need for a specific zcml statement to register layers, so your statement above confuses me. I'm proposing a consideration, later on, of special zcml to register layers for use in the ZMI. In addition, I'd like to say that I believe that it is important to keep things that are just for the ZMI separate from the "core", where they add complexity to the "core". -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
On Tuesday 13 December 2005 08:34, Philipp von Weitershausen wrote: > No, we just make the registration of layers optional. If you want layers > to be registered (and marked with an ILayerType marker) for whatever > reason, it's your choice. The framework shouldn't make you like it does > now. This will definitely backfire. Let's say I want to extend the wiki views using some TTW development. But the wiki package does not register the layer, then the TTW developer is cut off. Note that I am not saying that the *framework* should require this, but it should be at least a strong convention and people should do this registration all the time. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
Stephan Richter wrote: > On Tuesday 13 December 2005 06:15, Steve Alexander wrote: > >>I understand from this discussion that registering layers is needed only >>for certain ZMI things, to be implemented later on. So, I guess the >>ZCML will be implemented later on, or not implemented later on. In >>either case, later on. > > I disagree. The layers are registered now. You rip them out now, just so I > have to add them later again? That sounds dubious to me. No, we just make the registration of layers optional. If you want layers to be registered (and marked with an ILayerType marker) for whatever reason, it's your choice. The framework shouldn't make you like it does now. 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] RFC: Simplify Skinning Redux
On Tuesday 13 December 2005 06:15, Steve Alexander wrote: > I understand from this discussion that registering layers is needed only > for certain ZMI things, to be implemented later on. So, I guess the > ZCML will be implemented later on, or not implemented later on. In > either case, later on. I disagree. The layers are registered now. You rip them out now, just so I have to add them later again? That sounds dubious to me. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
On Tuesday 13 December 2005 04:30, Philipp von Weitershausen wrote: > That said, I still think that in the long term, local registration should > not be done TTW. Who said that I just want to register local components? :-) I want to attack true TTW development, similar to how ZClasses worked. I have a couple of use cases in mind that are not served with Zope 3 right now. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
Steve Alexander wrote: Who will use these interfaces? In what parts of the code will they be present? I think these marker interfaces are used only in infrastructure code to do with setting up layers and skins. In this case, they will not be typed often, and will not even be read often. So, I think it is more important that the name be clear than the name be short, so that it can be understood quickly upon reading it. As I mentioned, the dotted name already provides some semantics. IMO zope.app.publisher.browser.ISkinType does explicitly means that such a type is used for browser applications, otherwise it should be not within the browser package (unwritten convention). want your layer interface to show up for TTW view registration, you'll need ILayerType so that it shows up in the "Browser Layers" vocabulary and thus among the list of selectable layer interfaces. I strongly support this being an optional feature; a price you pay only if you care about TTW stuff. Me too. That said, I still think that in the long term, local registration should not be done TTW. So this optional notion of ILayerType might not be necessary in the future after all. For filesystem-based development I don't find any compelling usage for it at all. Me too. I'm not a TTW-fan at all, but IMO it is important that such a framework supports potential use cases as long we don't get unacceptable drawbacks. I'm really not interested in the never-ending file versus ttw development debate ;) Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
>>It is simple to create a zcml directive specifically for registering a >>layer. If there is a good reason to register layers, then I think there >>should be a zcml directive for it. > > I disagree. Just because it is simple to create new ZCML directives > doesn't mean we don't have to. The less special ZCML directives there > are, the less people need to learn and the more people can reuse > reoccurring idioms. That's a good thing. If we can pass on architectural > simplifications to the developer who's writing Python and ZCML, we > should do that. I see what you're saying. I didn't explain where I'm coming from. I think that the ZMI is really a separate product than the core of Zope 3. This is a controversial position to hold. >From that position, I think that if the ZMI product wants to define its own ZCML to make doing ZMI-related things easy, then it should. I understand from this discussion that registering layers is needed only for certain ZMI things, to be implemented later on. So, I guess the ZCML will be implemented later on, or not implemented later on. In either case, later on. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
Steve Alexander wrote: I would suggest to register the layers like skins using a ILayerBrowserType interface: >>> interface=".interfaces.I18NFeatures" type="zope.publisher.interfaces.browser.IBrowserLayerType" /> > > It is simple to create a zcml directive specifically for registering a > layer. If there is a good reason to register layers, then I think there > should be a zcml directive for it. I disagree. Just because it is simple to create new ZCML directives doesn't mean we don't have to. The less special ZCML directives there are, the less people need to learn and the more people can reuse reoccurring idioms. That's a good thing. If we can pass on architectural simplifications to the developer who's writing Python and ZCML, we should do that. 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] RFC: Simplify Skinning Redux
>>>I would suggest to register the >>>layers like skins using a ILayerBrowserType interface: >>> > interface=".interfaces.I18NFeatures" >>> type="zope.publisher.interfaces.browser.IBrowserLayerType" >>> /> It is simple to create a zcml directive specifically for registering a layer. If there is a good reason to register layers, then I think there should be a zcml directive for it. Of course, it may be that there's not really a good reason for registering layers. >>>2. I liked the naming ISkinType and ILayerType much more (instead of >>>IBrowserSkinType/ IBrowserLayerType), because this browser-specific >>>differentiation is already given by the package hierarchy and those >>>ILongCamelCaseWordingsThatTriesToExplainEverything are hard to type and >>>at the end they confuse newcomers even more than the simple ones. Please >>>keep the naming also simple and stupid like the skinning simplification >>>itself :) > > > I don't feel strongly about this at all. It was mostly Steve's idea and I > took his > suggestion as it adds some conherence (IBrowserRequest, IBrowserResponse, > IBrowserLayerType, ...). It would be up to Steve to defend it, for all I care > we can use > the shorter forms. Who will use these interfaces? In what parts of the code will they be present? I think these marker interfaces are used only in infrastructure code to do with setting up layers and skins. In this case, they will not be typed often, and will not even be read often. So, I think it is more important that the name be clear than the name be short, so that it can be understood quickly upon reading it. >>Two good points I agree with. I wanted to write a similar response as 1., but >>did not have a good argument. Dominik just gave it. I think it is important >>to keep a registry of all layers, especially for TTW development, an area I >>really want to put some effort in for 3.3. Why do you need a registry of all layers? What use-cases drive this requirement? Maybe you just need to be able to look them up? > Thanks, I guess this is a good use case. The good thing is that the whole > ILayerType thing > can be *optional*. This is important to me. The core of a publisher-with-layers can be based on just a request's interfaces. No need for extra complexity or infrastructure. It should be possible to strip a use of Zope 3 down to this level. > The 'type' argument of browser:page et.al. won't require an ILayerType > interface; any interface will do as long as it is or extends IBrowserRequest. This is important too. > Only if you > want your layer interface to show up for TTW view registration, you'll need > ILayerType so > that it shows up in the "Browser Layers" vocabulary and thus among the list > of selectable > layer interfaces. I strongly support this being an optional feature; a price you pay only if you care about TTW stuff. > That said, I still think that in the long term, local registration should not > be done TTW. > So this optional notion of ILayerType might not be necessary in the future > after all. For > filesystem-based development I don't find any compelling usage for it at all. Me too. > So, if there are no other comments on this proposal, I will update it with > your latest > suggestions and get started on the implementation (on a branch, of course). -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
Stephan Richter wrote: > On Monday 12 December 2005 16:29, Dominik Huber wrote: > > 1. The brand *skin* and *layer* are fairly common and they are > > reflecting two logical uses cases. At a first glance the usage for a > > layer type is not given, but the layer concept is still interesting to > > build modular skins. The layer audience could be the developers which > > like to share layer specific informations. IMO an use case for an > > Browser Layer Names utility could be a corresponding > > online-documentation within the api-doc. Well, the vocabulary would probably be a "Browser Layers" vocabulary (listing the actual interface objects, not their names, since layers won't have human-readable aliases anymore). However, I don't see how that vocabulary would be necessary for the documentation (it would be necessary for TTW development, see below). It's not like we mark every interface we have with some special marker and put it in a vocabulary, just so it shows up in a certain category in APIDoc. If you want to find the layer interface, you'll find it just fine by walking the code browser in APIDoc, as with any other interface or component. Layer interfaces are just marker interfaces; if we'd treat every kind of marker interface specially, we'd not be simplifying at all... > > I would suggest to register the > > layers like skins using a ILayerBrowserType interface: > > > > > interface=".interfaces.I18NFeatures" > > type="zope.publisher.interfaces.browser.IBrowserLayerType" > > /> > > > > > > 2. I liked the naming ISkinType and ILayerType much more (instead of > > IBrowserSkinType/ IBrowserLayerType), because this browser-specific > > differentiation is already given by the package hierarchy and those > > ILongCamelCaseWordingsThatTriesToExplainEverything are hard to type and > > at the end they confuse newcomers even more than the simple ones. Please > > keep the naming also simple and stupid like the skinning simplification > > itself :) I don't feel strongly about this at all. It was mostly Steve's idea and I took his suggestion as it adds some conherence (IBrowserRequest, IBrowserResponse, IBrowserLayerType, ...). It would be up to Steve to defend it, for all I care we can use the shorter forms. > Two good points I agree with. I wanted to write a similar response as 1., but > did not have a good argument. Dominik just gave it. I think it is important > to keep a registry of all layers, especially for TTW development, an area I > really want to put some effort in for 3.3. Thanks, I guess this is a good use case. The good thing is that the whole ILayerType thing can be *optional*. The 'type' argument of browser:page et.al. won't require an ILayerType interface; any interface will do as long as it is or extends IBrowserRequest. Only if you want your layer interface to show up for TTW view registration, you'll need ILayerType so that it shows up in the "Browser Layers" vocabulary and thus among the list of selectable layer interfaces. That said, I still think that in the long term, local registration should not be done TTW. So this optional notion of ILayerType might not be necessary in the future after all. For filesystem-based development I don't find any compelling usage for it at all. So, if there are no other comments on this proposal, I will update it with your latest suggestions and get started on the implementation (on a branch, of course). 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
Re: [Zope3-dev] RFC: Simplify Skinning Redux
On Monday 12 December 2005 16:29, Dominik Huber wrote: > 1. The brand *skin* and *layer* are fairly common and they are > reflecting two logical uses cases. At a first glance the usage for a > layer type is not given, but the layer concept is still interesting to > build modular skins. The layer audience could be the developers which > like to share layer specific informations. IMO an use case for an > Browser Layer Names utility could be a corresponding > online-documentation within the api-doc. I would suggest to register the > layers like skins using a ILayerBrowserType interface: > > interface=".interfaces.I18NFeatures" > type="zope.publisher.interfaces.browser.IBrowserLayerType" > /> > > > 2. I liked the naming ISkinType and ILayerType much more (instead of > IBrowserSkinType/ IBrowserLayerType), because this browser-specific > differentiation is already given by the package hierarchy and those > ILongCamelCaseWordingsThatTriesToExplainEverything are hard to type and > at the end they confuse newcomers even more than the simple ones. Please > keep the naming also simple and stupid like the skinning simplification > itself :) Two good points I agree with. I wanted to write a similar response as 1., but did not have a good argument. Dominik just gave it. I think it is important to keep a registry of all layers, especially for TTW development, an area I really want to put some effort in for 3.3. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
Philipp von Weitershausen wrote: (http://dev.zope.org/Zope3/SimplifySkinning) yet another overhaul. Basically, it now proposes to go one step further: Layers and skins will always be simple interfaces extending IBrowserRequest. The only difference between skins and layers is that only skins are registered as local utilities under a human readable name whereas layers are plain old boring interfaces with no extra marker (it's not needed at all). Along with that we can get rid of the and ZCML directives and simply reuse existing, much simpler directives from the standard Component Architecture ( and ). This is not only a good step towards reducing the ZCML directive proliferation, it's also a reflection of what's going on under the hood. If we simplify under the hood, the Zope 3 developer should benefit from that simplification as well. That's now happening. The rest of the changes deal with small harmonizations that should make the understanding of certain patterns easier (if they're always the same). Looking-for-comments-as-usual-ly +1 in general, but two cosmetics-change-requests. 1. The brand *skin* and *layer* are fairly common and they are reflecting two logical uses cases. At a first glance the usage for a layer type is not given, but the layer concept is still interesting to build modular skins. The layer audience could be the developers which like to share layer specific informations. IMO an use case for an Browser Layer Names utility could be a corresponding online-documentation within the api-doc. I would suggest to register the layers like skins using a ILayerBrowserType interface: 2. I liked the naming ISkinType and ILayerType much more (instead of IBrowserSkinType/ IBrowserLayerType), because this browser-specific differentiation is already given by the package hierarchy and those ILongCamelCaseWordingsThatTriesToExplainEverything are hard to type and at the end they confuse newcomers even more than the simple ones. Please keep the naming also simple and stupid like the skinning simplification itself :) Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
Stephan Richter wrote: > On Monday 12 December 2005 02:53, Philipp von Weitershausen wrote: > >>Basically, it now proposes to go one step further: Layers and skins will >>always be simple interfaces extending IBrowserRequest. The only difference >>between skins and layers is that only skins are registered as local >>utilities under a human readable name whereas layers are plain old boring >>interfaces with no extra marker (it's not needed at all). > > > Hold on, but skins and layers can also still extend other skins and layers > (as > they do now), right? Sure. I should have said: Layers and skins will always be simple interfaces **directly or indirectly** extending IBrowserRequest. The "indirectly" means by inheriting from some other skin or layer interface. 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] RFC: Simplify Skinning Redux
On Monday 12 December 2005 02:53, Philipp von Weitershausen wrote: > Basically, it now proposes to go one step further: Layers and skins will > always be simple interfaces extending IBrowserRequest. The only difference > between skins and layers is that only skins are registered as local > utilities under a human readable name whereas layers are plain old boring > interfaces with no extra marker (it's not needed at all). Hold on, but skins and layers can also still extend other skins and layers (as they do now), right? Because otherwise I do not see how you want to realize the proposal. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RFC: Simplify Skinning Redux
Hi there, after a good discussion with Steve Alexander, I gave my Simplify Skinning proposal (http://dev.zope.org/Zope3/SimplifySkinning) yet another overhaul. Basically, it now proposes to go one step further: Layers and skins will always be simple interfaces extending IBrowserRequest. The only difference between skins and layers is that only skins are registered as local utilities under a human readable name whereas layers are plain old boring interfaces with no extra marker (it's not needed at all). Along with that we can get rid of the and ZCML directives and simply reuse existing, much simpler directives from the standard Component Architecture ( and ). This is not only a good step towards reducing the ZCML directive proliferation, it's also a reflection of what's going on under the hood. If we simplify under the hood, the Zope 3 developer should benefit from that simplification as well. That's now happening. The rest of the changes deal with small harmonizations that should make the understanding of certain patterns easier (if they're always the same). Looking-for-comments-as-usual-ly 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
Re: [Zope3-dev] RFC: Simplify Skinning
Philipp von Weitershausen wrote: Thanks for the input so far, please revise it and let me know if you see any other issues. +1 I like it. Thank you! Your connotation assertion here is incorrect. The default layer stands for: "If the browser directive did not specify a layer, use the default layer." By default, the Basic and thus Rotterdam skin incorporate that layer, but others like Dominik and Garrett do not want to include that layer. Right. I wonder if we should make the 'layer' argument mandatory then. Right now we have the connotation "You can leave the layer argument out in which case Zope will use some arbitrary layer that might or might not be in your skins and is boldly called 'default'." I find the current optional layer argument ok. In our current pratice we allways use the default for the basic or general views of a package. This offers a simple way to configure a out-of-the-box-general-purpose-administration-skin like the Rotterdam whitout the drawback that such a general skin should have to know a dedicated layer itself. If we provide other dedicated layers we always do additional registrations to those layers. A fairly usefull pattern that becomes manifest in our pratice: 1. Layers for one or more features belonging together. For such a unit we define three different layers that covers the following aspects of an application: -> minimal_feature layer: Invisible functionality like traverser that should be there even if there is no ui -> user_feature layer: All views for general end-user usage -> admin_featur layer: Views for administration purposes. (One example for a minimal layer tiks svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/skins/minimal) 2. Those feature layers are used to compose the a custom skin afterwards. -> pretty modular and clearly arranged whitout beeing to granular. 3. Because we still register to the default layer a general zmi like the rotterdam skin can be used too. ->this is cool, because everybody can use its favority general-purpose skin and it doesn't hurts his brain to guess where he should configure something (compared to plone in hybrid zope2/plone applications) Maybe we should introduce a minimal_zope_core and other important layers which might simplify such application for all parties. Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning
Stephan Richter wrote: > On Wednesday 07 December 2005 16:33, Dominik Huber wrote: > > Phillip's Proposal: > > Furthermore, I propose to remove the |IDefaultLayer| interface. We've > > been using the |default| layer as a connotation of "always being > > available unless overridden by a more specific layer." However, this > > does not apply all the time: When the |default| layer is not included in > > a specific skin, nothing from the |default| layer will be found even > > though the ZCML statements suggest that it would always be available. I > > therefore propose to make the |default| skin layer an alias for > > |IBrowserRequest|. Anything registered for |default| will obviously > > always be available then, no matter what your skin layer looks like. > > Oops, I missed that part. -1 on it, like Dominik. I originally did not have an > IDefaultLayer when I converted views to adapters and it caused a lot of > headaches for people. It was thus added and we all agreed it was needed. Very well, I wasn't aware of the fact that it was commonly undestood that IDefaultLayer was needed. The original proposal (http://dev.zope.org/Zope3/ImplementViewsAsAdapters) certainly doesn't mention it. I've now found the relevant check-in where it was introduced (http://mail.zope.org/pipermail/zope3-checkins/2004-November/023621.html). The benefits are stated there, but the actual reasoning is in CHANGES.txt where it says "[IDefaultLayer] allows developers to create skins that do not include the default layer." I guess the proposal should have been updated with this info and a sentence saying that there actually *are* developers with the use case of creating skins sans default layer. At least it would have made things clearer to me from the beginning ;). Anyways, I overhauled the proposal now to include lots of useful suggestions from you, Martijn, and Dominik. Thanks for the input so far, please revise it and let me know if you see any other issues. > Your connotation assertion here is incorrect. The default layer stands for: > "If the browser directive did not specify a layer, use the default layer." By > default, the Basic and thus Rotterdam skin incorporate that layer, but others > like Dominik and Garrett do not want to include that layer. Right. I wonder if we should make the 'layer' argument mandatory then. Right now we have the connotation "You can leave the layer argument out in which case Zope will use some arbitrary layer that might or might not be in your skins and is boldly called 'default'." 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
Re: [Zope3-dev] RFC: Simplify Skinning
Quoting Dominik Huber <[EMAIL PROTECTED]>: > Phillip's Proposal: > Furthermore, I propose to remove the |IDefaultLayer| interface. We've > been using the |default| layer as a connotation of "always being > available unless overridden by a more specific layer." However, this > does not apply all the time: When the |default| layer is not included in > a specific skin, nothing from the |default| layer will be found even > though the ZCML statements suggest that it would always be available. I > therefore propose to make the |default| skin layer an alias for > |IBrowserRequest|. Anything registered for |default| will obviously > always be available then, no matter what your skin layer looks like. > > -1 > I really appreciate that I can disable all registrations if I do not > derive a skin from the default layer. That's very important use case for > us. We introduced a minimal layer that is providing only the most > important functionality like traversers etc. Regularly we derive > end-user skins from this minimal layer and then we register all views > explicitly so that we have full controll over accessibility of information. Very well, I didn't think there were use cases for this. I guess there are. Thanks for letting me know! I've given the proposal a general overhaul and ripped out this suggestion as well. Please revise it again and let me know if you see any other issues. Continuing-to-RFC-ly 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
Re: [Zope3-dev] RFC: Simplify Skinning
I don't have much constructive to add to this, but the discussion itself has really given me a much better understanding of the reasons for the complexity of the current skinning system. I would still like to see it simplified, but I feel far more empowered to properly use it after reading the proposal and this discussion. Thanks everyone! Alec Munro On 12/7/05, Stephan Richter <[EMAIL PROTECTED]> wrote: > On Wednesday 07 December 2005 16:33, Dominik Huber wrote: > > Phillip's Proposal: > > Furthermore, I propose to remove the |IDefaultLayer| interface. We've > > been using the |default| layer as a connotation of "always being > > available unless overridden by a more specific layer." However, this > > does not apply all the time: When the |default| layer is not included in > > a specific skin, nothing from the |default| layer will be found even > > though the ZCML statements suggest that it would always be available. I > > therefore propose to make the |default| skin layer an alias for > > |IBrowserRequest|. Anything registered for |default| will obviously > > always be available then, no matter what your skin layer looks like. > > Oops, I missed that part. -1 on it, like Dominik. I originally did not have an > IDefaultLayer when I converted views to adapters and it caused a lot of > headaches for people. It was thus added and we all agreed it was needed. > > Your connotation assertion here is incorrect. The default layer stands for: > "If the browser directive did not specify a layer, use the default layer." By > default, the Basic and thus Rotterdam skin incorporate that layer, but others > like Dominik and Garrett do not want to include that layer. > > Regards, > Stephan > -- > Stephan Richter > CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) > Web2k - Web Software Design, Development and Training > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/alecmunro%40gmail.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] RFC: Simplify Skinning
On Wednesday 07 December 2005 16:33, Dominik Huber wrote: > Phillip's Proposal: > Furthermore, I propose to remove the |IDefaultLayer| interface. We've > been using the |default| layer as a connotation of "always being > available unless overridden by a more specific layer." However, this > does not apply all the time: When the |default| layer is not included in > a specific skin, nothing from the |default| layer will be found even > though the ZCML statements suggest that it would always be available. I > therefore propose to make the |default| skin layer an alias for > |IBrowserRequest|. Anything registered for |default| will obviously > always be available then, no matter what your skin layer looks like. Oops, I missed that part. -1 on it, like Dominik. I originally did not have an IDefaultLayer when I converted views to adapters and it caused a lot of headaches for people. It was thus added and we all agreed it was needed. Your connotation assertion here is incorrect. The default layer stands for: "If the browser directive did not specify a layer, use the default layer." By default, the Basic and thus Rotterdam skin incorporate that layer, but others like Dominik and Garrett do not want to include that layer. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning
Martijn Faassen wrote: Philipp von Weitershausen wrote: Looking for your comments at http://dev.zope.org/Zope3/SimplifySkinning. This is a follow-up proposal from http://www.zope.org/Collectors/Zope3-dev/444. I rather like having the *concept* skin to talk about. While implementation-wise things may become cleaner, being able to talk about a skin is I think a bit more clear than if you talk about skin layers. Similarly, I think it's a useful concept to talk to a layout developer about 'layers' as a separate concept, to indicate to them that a layer is not something necessarily directly exposed to an end user. I think that this use case is less strong than the one for maintaining the word 'skin', though. In various use cases, for instance Silva, there's a class of users that just wants to select from a list of skins installed for their site, and has no knowledge of how they're implemented. You don't want to show all layers to them. It would therefore be nice to have a way to mark particular skin layers as actual skins you want to expose to end-users, not just as things useful as a building block. This is something we use the skin mechanism for now, and that facility would, if I understand it correctly, go away in this proposal. +1 to all those Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dominik.huber%40perse.ch -- Dominik Huber Perse Engineering GmbH Jurastrasse 9a CH-5406 Baden E-Mail: [EMAIL PROTECTED] Telefon: ++41 56 534 7730 begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning
Phillip's Proposal: Furthermore, I propose to remove the |IDefaultLayer| interface. We've been using the |default| layer as a connotation of "always being available unless overridden by a more specific layer." However, this does not apply all the time: When the |default| layer is not included in a specific skin, nothing from the |default| layer will be found even though the ZCML statements suggest that it would always be available. I therefore propose to make the |default| skin layer an alias for |IBrowserRequest|. Anything registered for |default| will obviously always be available then, no matter what your skin layer looks like. -1 I really appreciate that I can disable all registrations if I do not derive a skin from the default layer. That's very important use case for us. We introduced a minimal layer that is providing only the most important functionality like traversers etc. Regularly we derive end-user skins from this minimal layer and then we register all views explicitly so that we have full controll over accessibility of information. Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning
Martijn Faassen wrote: > Philipp von Weitershausen wrote: > >> Looking for your comments at http://dev.zope.org/Zope3/SimplifySkinning. >> This is a follow-up proposal from >> http://www.zope.org/Collectors/Zope3-dev/444. > > I rather like having the *concept* skin to talk about. While > implementation-wise things may become cleaner, being able to talk about > a skin is I think a bit more clear than if you talk about skin layers. > > Similarly, I think it's a useful concept to talk to a layout developer > about 'layers' as a separate concept, to indicate to them that a layer > is not something necessarily directly exposed to an end user. I think > that this use case is less strong than the one for maintaining the word > 'skin', though. > > In various use cases, for instance Silva, there's a class of users that > just wants to select from a list of skins installed for their site, and > has no knowledge of how they're implemented. You don't want to show all > layers to them. > > It would therefore be nice to have a way to mark particular skin layers > as actual skins you want to expose to end-users, not just as things > useful as a building block. This is something we use the skin mechanism > for now, and that facility would, if I understand it correctly, go away > in this proposal. It's a good use-case, but not much of a problem. As you said, it's not about the implementation, it's about presenting a decent list to the user. Skins and layers (and after my proposal skin layers, too) are registered as utilities providing ISkin or ILayer (and after my proposal, ISkinLayerType). You could create an interface, e.g. called IUserSelectSkinLayerType, which extends ISkinLayerType. All skin layers that are skins in the old sense (IOW, being choosable by users) would be registered as utilities with this interface. You could then use a UtilityVocabulary to pull out all user-selectable skin layers easily into a Choice field or whatever. If you think such an interface and perhaps the vocabulary should be in Zope itself, fine by me. We could ammend the proposal. 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] RFC: Simplify Skinning
Stephan Richter wrote: > On Wednesday 07 December 2005 09:47, Philipp von Weitershausen wrote: > >>If I understand you correctly, you just propose to keep layers and get >>rid of skins while I roughly propose to do it the other way around. I >>really don't see a big difference :). > > > The difference is in effort. :-) If we keep layers around, there is no need > to > changed any browser directive, but if we keep skin around, then we have to > change eventually all browser:* directives "layer" attribute to "skin". If you read my proposal carefully, you'll see that I never proposed to change any ZCML directive parameter. > Also, you called the new interface "ISkinLayerType". Layer is the more > general > term, so you really proposed to keep layers around as well. :-) No I didn't. I don't follow your thinking here. I proposed to consolidate the concepts into one. Whether we call that "layer" or "skin layer", I don't really care. I guess you propose to call it "layer" whereas "skin" would be a conceptual term based on layers (like view is a conceptual term based on adapters). > Personally I like layers better anyways, since it makes conceptually more > sense to me. I'm not really choosing one over the other conceptually, maybe only from a nomenclature point of view. > As to Martijn's comments, I think that the term "skin" can still be around, > like the term "view" does, but it should be a conceptual term, not an > implemented one. Right. 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] RFC: Simplify Skinning
Stephan Richter wrote: On Wednesday 07 December 2005 09:15, Martijn Faassen wrote: In various use cases, for instance Silva, there's a class of users that just wants to select from a list of skins installed for their site, and has no knowledge of how they're implemented. You don't want to show all layers to them. Why not? Currently there is only one layer more than there are skins, namely the IDefaultLayer. Whenever I write a layer I also write a skin, and this has been really annoying. Please remember, Zope 3 core is not all the applications that use Zope 3. In Zope 3 core, currently there's only one more layer than there are skins. This is not necessarily true for all applications that use Zope 3. It would therefore be nice to have a way to mark particular skin layers as actual skins you want to expose to end-users, not just as things useful as a building block. This is something we use the skin mechanism for now, and that facility would, if I understand it correctly, go away in this proposal. Right, if this deems necessary, it would be very easy to tag on another type interface specifying a skin in comparison to a regular layer. My point is to make people aware of this use case. It may be something we have to solve on the application side with tagging, etc, but it would also mean the framework is doing less for us than it is doing now, where we can just ask for a list of skins. 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] RFC: Simplify Skinning
On Wednesday 07 December 2005 09:15, Martijn Faassen wrote: > In various use cases, for instance Silva, there's a class of users that > just wants to select from a list of skins installed for their site, and > has no knowledge of how they're implemented. You don't want to show all > layers to them. Why not? Currently there is only one layer more than there are skins, namely the IDefaultLayer. Whenever I write a layer I also write a skin, and this has been really annoying. > It would therefore be nice to have a way to mark particular skin layers > as actual skins you want to expose to end-users, not just as things > useful as a building block. This is something we use the skin mechanism > for now, and that facility would, if I understand it correctly, go away > in this proposal. Right, if this deems necessary, it would be very easy to tag on another type interface specifying a skin in comparison to a regular layer. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning
On Wednesday 07 December 2005 09:47, Philipp von Weitershausen wrote: > If I understand you correctly, you just propose to keep layers and get > rid of skins while I roughly propose to do it the other way around. I > really don't see a big difference :). The difference is in effort. :-) If we keep layers around, there is no need to changed any browser directive, but if we keep skin around, then we have to change eventually all browser:* directives "layer" attribute to "skin". Also, you called the new interface "ISkinLayerType". Layer is the more general term, so you really proposed to keep layers around as well. :-) Personally I like layers better anyways, since it makes conceptually more sense to me. Also translating skin always provided troubles. As to Martijn's comments, I think that the term "skin" can still be around, like the term "view" does, but it should be a conceptual term, not an implemented one. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning
Stephan Richter wrote: >>Looking for your comments at http://dev.zope.org/Zope3/SimplifySkinning. >>This is a follow-up proposal from >>http://www.zope.org/Collectors/Zope3-dev/444. > > > I was going to write a similar proposal for 3.3 as well. I think we should > simply get rid of skins and pretend they never existed. > > Some comments: > > * 'ISkinLayerType' is introduced to mark skin layers interfaces. > > Just call it ILayer. > > * 'ISkin' is made an alias of 'ISkinLayerType', deprecated and > slated for removal in Zope 3.4. > > Yep, gone and goner. > > * 'ILayer' is made to extend 'ISkinLayerType' but also deprecated > and slated for removal in Zope 3.4. > > Don't deprecate it. It's still useful. Why? It's not more or less useful than ISkin. If I understand you correctly, you just propose to keep layers and get rid of skins while I roughly propose to do it the other way around. I really don't see a big difference :). 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] RFC: Simplify Skinning
Philipp von Weitershausen wrote: Looking for your comments at http://dev.zope.org/Zope3/SimplifySkinning. This is a follow-up proposal from http://www.zope.org/Collectors/Zope3-dev/444. I rather like having the *concept* skin to talk about. While implementation-wise things may become cleaner, being able to talk about a skin is I think a bit more clear than if you talk about skin layers. Similarly, I think it's a useful concept to talk to a layout developer about 'layers' as a separate concept, to indicate to them that a layer is not something necessarily directly exposed to an end user. I think that this use case is less strong than the one for maintaining the word 'skin', though. In various use cases, for instance Silva, there's a class of users that just wants to select from a list of skins installed for their site, and has no knowledge of how they're implemented. You don't want to show all layers to them. It would therefore be nice to have a way to mark particular skin layers as actual skins you want to expose to end-users, not just as things useful as a building block. This is something we use the skin mechanism for now, and that facility would, if I understand it correctly, go away in this proposal. 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] RFC: Simplify Skinning
On Wednesday 07 December 2005 03:55, Philipp von Weitershausen wrote: > Looking for your comments at http://dev.zope.org/Zope3/SimplifySkinning. > This is a follow-up proposal from > http://www.zope.org/Collectors/Zope3-dev/444. I was going to write a similar proposal for 3.3 as well. I think we should simply get rid of skins and pretend they never existed. Some comments: * 'ISkinLayerType' is introduced to mark skin layers interfaces. Just call it ILayer. * 'ISkin' is made an alias of 'ISkinLayerType', deprecated and slated for removal in Zope 3.4. Yep, gone and goner. * 'ILayer' is made to extend 'ISkinLayerType' but also deprecated and slated for removal in Zope 3.4. Don't deprecate it. It's still useful. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RFC: Simplify Skinning
Looking for your comments at http://dev.zope.org/Zope3/SimplifySkinning. This is a follow-up proposal from http://www.zope.org/Collectors/Zope3-dev/444. 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
