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
