Re: [Zope3-dev] Simplify Skinning ready for review / work on Reducing the Amount of ZCML Directives
Gary Poster wrote: Dominik Huber wrote: Now that this proposal has been dealt with, I will turn my focus of attention to http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives. [...] I like those simplifications, but I have two little objections... [...] The class/implements subdirective is debatable because putting an interface on a class might be considered some sort of policy. So I don't feel too strong about it. Strong -1 on removing class/implements. We use this frequently to apply policy from one package to a content object in a second unrelated package, from within a third package that depends on both. Sounds like an interesting usecase. I definitely agree about marker interfaces being on/off switches for certain policy. My motivation for removing class/implements wasn't that I didn't see the usecases. It is that the class directive as it is now mixes one kind of policy setup (security) with another kind (marker interface). Perhaps we shouldn't get rid of class/implements but just move it out of the class directive into its own one. Then it would also possible to make more implements calls without having conflicts on the class directive. Making security assertions only needs to happen once, putting marker interfaces on a class could happen more than once (your usecase almost seems to suggest it). Also note that Five has a five:implements directive which works exactly like the top-level implements directive I'm suggesting to create in place of class/implements. It is known to be used more than once on the same class. I updated the proposal accordingly, though so far only at http://codespeak.net/svn/user/philikon/ReducingTheAmountOfZCMLDirectives.txt since zope.org seems to be down right now. I'll miss class/factory, but agree that it is an example of the magic you are trying to remove. Yup. Plus, it wouldn't make much sense removing factory and not class/factory. 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] Simplify Skinning ready for review / work on Reducing the Amount of ZCML Directives
Philipp von Weitershausen wrote: [...] I would vote to leave at least the class/factory and class/implements subdirectives. The class/implements subdirective is debatable because putting an interface on a class might be considered some sort of policy. So I don't feel too strong about it. Thanks :) The class/factory case however is clearly about automation. Yes, one aspect. This aspect is very important too. I love this automation and I'm probably not the only one. Look at Gary's statement I'll miss class/factory, As demonstrated in the proposal, the Python version with a simple utility directive is only two or so lines longer and essentially moves most of the information from ZCML to Python code. The move from ZCML to Python is often better, but not always. I tried to sketch the use case *including a class from an external library into an application*. My balance based on the attached example [1] summarizes the following: A) Extensive today: 10 text-lines in zcml B) Lazy today: 6 text-lines in zcml C) Exentsive proposed: 1O text-lines in zcml, 8 text-lines in py-module + retyping the IFactory-import each time D) Lazy proposed: 1O text-lines in zcml, 8 text-lines in py-module + retyping the IFactory-import each time So, the proposed solution is about 3 times (*not* 3 lines ;) costlier than the laziest-manner. It also reuses the well-known utility directive which makes registering factories very coherent: No matter whether they are custom or based on a callable like a factory from class, you just use the utility directive. Coherence is one of the initial problems I state in the proposal so I rather feel strongly about the class/factory case. I really support coherence and less-magic attempts, but in this case the price is definitely to high and the intended simplification is fairly questionable. The class/factory and createObject-pattern was always understandable for the Newbies I've met during the mini-sprints. The whole component-architecture in particular the adapter- and utility-mechanism was much more magic for them. Automation will stay a magic, but it enables often people to do things they don't fully (deeply) understand. IMO it's more important to offer coherent magics on a certain application-layer than to evangelise assembler or even quantum mechanics. As well there the magic will come back at a certain point on a deeper application level :) Still a very strong -1 on removing class/factory. Regards, Dominik [1] Example: A) Extensive today -- Today I have to write one ZCML...: class class=.alias.SydneyBristow implements interface=.interface.ISydneyBristowPolicyMarker / factory id=external.library.SydneyBristow title=Agent Sydney Bristow description=Sydney is an undercover agent working for the CIA / ... /class B) Lazy today - or in the laziest manner (B): class class=.alias.SydneyBristow implements interface=.interface.ISydneyBristowPolicyMarker / factory / ... /class Remark: Afterward I can use the zope.component.createObject(external.library.SydneyBristow) to create instances. C) Extensive proposed - After the proposed change I have to do the following: additional module for example alias.py: from zope.component.factory import Factory from external.library import SyndeyBristow sydneyFactory = Factory( SyndeyBristow, # a callable, e.g. a class title=(u'Agent Sydney Bristow'), description=(u'Sydney is an undercover agent working for the CIA') ) ZCML to register the class and the factory utility: class class=.alias.SydneyBristow implements interface=.interface.ISydneyBristowPolicyMarker / ... /class utility component=.alias.sydneyFactory provides=zope.component.interfaces.IFactory? http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ReducingTheAmountOfZCMLDirectives/editform?page=IFactory name=alias.SydneyBristow? http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ReducingTheAmountOfZCMLDirectives/editform?page=SydneyBristow / D) Lazy proposed dito - 2 text lines ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Simplify Skinning ready for review / work on Reducing the Amount of ZCML Directives
On Tue, 2006-02-21 at 17:08 +0100, Philipp von Weitershausen wrote: Hi there, a large portion of http://dev.zope.org//SimplifySkinning has been implemented in the philikon-simplify-skinning branch. Please check it out and give me feedback. The 'Browser Skin Names' vocabulary has not been implemented yet. This is a no-brainer and will follow tomorrow or so. I didn't get to view thiswhere is it moved to? Andrew ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Simplify Skinning ready for review / work on Reducing the Amount of ZCML Directives
Philipp von Weitershausen wrote: Now that this proposal has been dealt with, I will turn my focus of attention to http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives. Since my initial announcement of the proposal I made some minor ammendments regarding the 'content' directive. Please check them out and give me feedback. I plan to start working on the implementation this week. I like those simplifications, but I have two little objections... The factory directive particularly within the class directive is very convenient and I use them fairly often. So I would miss that shortcut, because it saves a few lines of replicated code :( In addition the coupling of class/factory and class/implements is very concise and handy too, if you like to include 'external' packages into your application. In such a case I don't like to write an extra modul for the factory implementation and the class-implements-declaration. IMO this use case is focused to a component registration aspect and zcml would be the right place to cover it. I would vote to leave at least the class/factory and class/implements subdirectives. Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Simplify Skinning ready for review / work on Reducing the Amount of ZCML Directives
Andrew Sawyers wrote: a large portion of http://dev.zope.org//SimplifySkinning has been implemented in the philikon-simplify-skinning branch. Please check it out and give me feedback. The 'Browser Skin Names' vocabulary has not been implemented yet. This is a no-brainer and will follow tomorrow or so. I didn't get to view thiswhere is it moved to? Sorry, bad link: http://dev.zope.org/Zope3/SimplifySkinning ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Simplify Skinning ready for review / work on Reducing the Amount of ZCML Directives
Dominik Huber wrote: Now that this proposal has been dealt with, I will turn my focus of attention to http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives. Since my initial announcement of the proposal I made some minor ammendments regarding the 'content' directive. Please check them out and give me feedback. I plan to start working on the implementation this week. I like those simplifications, but I have two little objections... The factory directive particularly within the class directive is very convenient and I use them fairly often. So I would miss that shortcut, because it saves a few lines of replicated code :( In addition the coupling of class/factory and class/implements is very concise and handy too, if you like to include 'external' packages into your application. In such a case I don't like to write an extra modul for the factory implementation and the class-implements-declaration. IMO this use case is focused to a component registration aspect and zcml would be the right place to cover it. I would vote to leave at least the class/factory and class/implements subdirectives. The class/implements subdirective is debatable because putting an interface on a class might be considered some sort of policy. So I don't feel too strong about it. The class/factory case however is clearly about automation. As demonstrated in the proposal, the Python version with a simple utility directive is only two or so lines longer and essentially moves most of the information from ZCML to Python code. It also reuses the well-known utility directive which makes registering factories very coherent: No matter whether they are custom or based on a callable like a factory from class, you just use the utility directive. Coherence is one of the initial problems I state in the proposal so I rather feel strongly about the class/factory case. 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] Simplify Skinning ready for review / work on Reducing the Amount of ZCML Directives
On Feb 21, 2006, at 7:15 PM, Philipp von Weitershausen wrote: Dominik Huber wrote: Now that this proposal has been dealt with, I will turn my focus of attention to http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives. [...] I like those simplifications, but I have two little objections... [...] The class/implements subdirective is debatable because putting an interface on a class might be considered some sort of policy. So I don't feel too strong about it. Strong -1 on removing class/implements. We use this frequently to apply policy from one package to a content object in a second unrelated package, from within a third package that depends on both. I'll miss class/factory, but agree that it is an example of the magic you are trying to remove. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
