Fwd: [Zope3-dev] a new zcml directive?
I wrote this reply earlier but forgot to use 'reply all' instead of 'reply'. Oops. I'm also editing and expanding my remarks slightly from the earlier. In short: Python is a good programming language, usually easy to follow. ZCML is not. Either work really hard at improving ZCML, or just simplify it. I'm having more headaches and misery with it as time goes by, and the last thing I need is more and more directives when I get infuriated by the ones that currently exist. On 3/13/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: > Marius Gedminas wrote: > [snip] > > -1 > > > > I'd prefer > > > > from zope.annotation.adapter import AnnotationAdapter > > > > getFoo = AnnotationAdapter(for_=IBar, > >interface=IFoo, > >factory=Foo, > >key=FOO_KEY) > > # I suppose the key could be optional; you could use a > > # dotted interface name by default > > > > and then the ordinary > > > > > > > > I think this is exactly the same as Jeff Shell's suggestion, but its > > 3am, and I'm too tired to read his entire message. > > I guess it comes down to the question whether annotations are a basic > configuration concept, like views, and thus have their own directive to > register them, or not. It seems like we just had the debate and decision that ZCML was doing too much. Yes - I sometimes prefer to see (especially in a class directive) over . But in general, I want ZCML to be simple. I hate editing it. The more that I have to do in ZCML, the less that I want to do it. The less that I want to keep on using Zope. I have had too many frustrations in recent weeks. We have a good programming language. We should use it as much as possible. > In your example, the ZCML doesn't show that we actually are setting up > an annotation, and it doesn't show for what we're setting up an > annotation for in the first place either. It's one intrepretation of > ZCML that it should show these things. The other interpretation of ZCML > is that its main task is just hooking components into the system. I'm totally with the second option. I'd rather have the Python code say that it's an annotation than the ZCML. And I hate having to duplicate that information. I know that if I'm going to have ZCML say "provides='...'", I don't need to have 'adapts(...)' in my Python code. But then I find myself staring at my Python code and going "uh, what does this class do again?" I'd rather let the Python code say it. I hate seeing views documented (and implemented) like this: class Search: ... No 'implements', no superclass, no adapts, nothing. It means there's some other file somewhere else that is modifying this classes behavior that I have to look at and change my internal parsing mode to read and understand. And since I got bit by this again recently (trying to subclass from formlib's 'SubPageForm but registered with ZCML as a viewlet caused my __init__ override to go boom and I didn't know at that point which signature to implement), my anger with the system has grown. > Perhaps we should make explicit which ZCML we want to have, as its > design can be quite different depending on that choice. I still appreciate ZCML, but only in its most simplistic form. I think it's applicable for: * "I have an adapter and would like to register it" * "I have a utility and would like to register it" * "I have a class and would like to apply security options to it and a couple of other declarations (additional interfaces supported, a factory, etc)" * "I have an interface, and I'd like to say that all things that implement it are things of type x" * "I'd like to load and configure this package now" I think ZCML should *and only should* be used to basically register code to run separately from Python imports. That means it shouldn't be making new components on the fly. That starts to compound its job. Its job should be, in my arrogant opinion, saying "Here's some Python code - an object, a function, a class, whatever - and what it means to Zope (is it an adapter? a utility? or a class that needs security restrictions applied and supports common mega-interfaces *like* IAnnotatable)". That's very different than automation. The automation is "I have a thing, or want a thing, that does this: go forth and generate it dynamically for me." Whether it's an annotation adapter, or an edit form, or a viewlet, there are now extra objects that don't really exist in any Python module that can be easily inspected, introspected, etc. They are phantoms generated by the machine. You have to have them to make certain things work. But what they are isn't obvious. They become painful to debug, introspect, etc. It really seems like one of the goals/ideas for ZCML was that you could make a crazy application with Zero Python Code - just use a lot of ZCML and it will generate everything for you. Or use ZCML, an interfaces.py module with some schema, and have a couple of persistent classes, and t
Re: [Zope3-dev] a new zcml directive?
Stephan Richter <[EMAIL PROTECTED]> writes: > On Friday 10 March 2006 10:19, Martijn Faassen wrote: >> What do people think? > > +1 We use this pattern for every annotation in SchoolTool and it gets old > really quick. One argument that could be made is that the code in the > function could be in the constructor. This is bad, because the __init__ > method should not do any "writing" on other objects. > I looked at the schooltool code a while ago and the annotation thing was something that I also noted as duplicated in there. Since I wanted to use annotations in a similar way I wrote a package that defines such an annotation ZCML directive. You can download the package here: http://dev.gentoo.org/~wrobel/zope.annotation.tar.bz2. It still has a weird hack in the README.txt and is not polished in any way but I believe it should work. I am a Zope3 newbie so don't expect too much From the thing. But I thought it might be of interest to the ongoing discussion. Don't hesitate to tell me why the package sucks :) Still eager to learn more about Zope. Regards Gunnar -- Gunnar WrobelGentoo Developer __C_o_n_t_a_c_t__ Mail: [EMAIL PROTECTED] WWW: http://www.gunnarwrobel.de IRC: #gentoo-web at freenode.org _ pgp6SExTFynI4.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] a new zcml directive?
On Monday 13 March 2006 06:20, Martijn Faassen wrote: > In your example, the ZCML doesn't show that we actually are setting up > an annotation, and it doesn't show for what we're setting up an > annotation for in the first place either. It's one intrepretation of > ZCML that it should show these things. The other interpretation of ZCML > is that its main task is just hooking components into the system. Yes, I agree with that. I tend to like the first one and use it that way. I commonly use the ZCML File of a package to get an overview of what features it provides. > Perhaps we should make explicit which ZCML we want to have, as its > design can be quite different depending on that choice. Yes, I think this would be a good idea. 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] a new zcml directive?
Marius Gedminas wrote: [snip] -1 I'd prefer from zope.annotation.adapter import AnnotationAdapter getFoo = AnnotationAdapter(for_=IBar, >interface=IFoo, >factory=Foo, key=FOO_KEY) > # I suppose the key could be optional; you could use a > # dotted interface name by default and then the ordinary I think this is exactly the same as Jeff Shell's suggestion, but its 3am, and I'm too tired to read his entire message. I guess it comes down to the question whether annotations are a basic configuration concept, like views, and thus have their own directive to register them, or not. In your example, the ZCML doesn't show that we actually are setting up an annotation, and it doesn't show for what we're setting up an annotation for in the first place either. It's one intrepretation of ZCML that it should show these things. The other interpretation of ZCML is that its main task is just hooking components into the system. Perhaps we should make explicit which ZCML we want to have, as its design can be quite different depending on that choice. 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] a new zcml directive?
Lennart Regebro wrote: On 3/10/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: For instance, one that looks like this: That doesn't look like configuration. What does it look like to you? If hooking up adapters is considered to be configuration, why is hooking up annotations not configuration? 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] a new zcml directive?
On 3/10/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: > For instance, one that looks like this: > > That doesn't look like configuration. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] a new zcml directive?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shell wrote: > On 3/10/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: >> A possibly valid direction we haven't discussed yet is to embrace ZCML's >> flexibility and make new high level directives often. For instance, >> every time I feel like I'm repeating myself in ZCML, maybe I should make >> a new high level directive to eliminate the repetition. The risk is >> that configuration ends up more magical, but maybe new tools can >> mitigate that risk. Thoughts? > > No. No no no no no no no no no no no no no no no no no no no no no no > no no no no no no no no no no no no no no no no no no no no no no no > no no. I suspect that if I had bothered to ask questions like this before designing the CMF, I never would have gotten anywhere. I don't think I'm going to ask anymore. :-) Shane -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEEll+A+xzD9r1eLsRAhCwAKC19KD71i/y2eY3hle8Fvy+Jn7lBQCgvbNF u88bunU98ZYh1ULhLp71VIo= =IjTN -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] a new zcml directive?
On Fri, Mar 10, 2006 at 04:19:44PM +0100, Martijn Faassen wrote: > Hi there, > > I notice a pattern in code that uses annotations that looks like this: > > class Foo(Persistent, Contained): > implements(interfaces.IFoo) > > def getFoo(context): > annotations = IAnnotations(context) > try: > return annotations[FOO_KEY] > except KeyError: > foo = Foo() > annotations[FOO_KEY] = foo > # to please security... > zope.app.container.contained.contained( > foo, context, 'foo') > return foo > > # Convention to make adapter introspectable > getFoo.factory = Foo > > If I'm doing this quite a bit, this looks like something that would be > better expressed in a... new ZCML directive (..waiting for the crowd to > start flinging stones). > For instance, one that looks like this: > > > > where the factory actually points to whatever creates the real > annotation (such as the Foo class in this case), not to the boilerplate > to attach it to the proper object. The boilerplate would go away from my > code, you could use the facility too without thought, and we'd all be > happy. :) -1 I'd prefer from zope.annotation.adapter import AnnotationAdapter getFoo = AnnotationAdapter(for_=IBar, interface=IFoo, factory=Foo, key=FOO_KEY) # I suppose the key could be optional; you could use a dotted # interface name by default and then the ordinary I think this is exactly the same as Jeff Shell's suggestion, but its 3am, and I'm too tired to read his entire message. Marius Gedminas -- We have an advanced scalable groupware communication environment (email) -- Alan Cox signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] a new zcml directive?
On 3/10/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Martijn Faassen wrote: > > If I'm doing this quite a bit, this looks like something that would be > > better expressed in a... new ZCML directive (..waiting for the crowd to > > start flinging stones). > > A possibly valid direction we haven't discussed yet is to embrace ZCML's > flexibility and make new high level directives often. For instance, > every time I feel like I'm repeating myself in ZCML, maybe I should make > a new high level directive to eliminate the repetition. The risk is > that configuration ends up more magical, but maybe new tools can > mitigate that risk. Thoughts? No. No no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no. There are very few ZCML directives whose code I can read. It's way too mystical and magical and full of weird things that I *still* don't understand like 'discriminator'. And there are leading and tailing underscores all over the place. This bit me like a mother recently when I was trying to write a unit test to cover a bug I found in my own code. It depended on me setting up enough of the test environment to mimic what was happening. It wasn't quite 'smallest unit of work' type unit testing as could/should often be done. But it was the amount of detective work and pain and trial and error and trial and error and trial and error to follow so many ZCML trails to set up what I needed for my test that really kicked off my recent round of frustration. A 3 line test, a 4 line fix, and over a hundred lines of imports / helpers / harness support from a long day's work into the night to support those seven lines... And really, so much of it was just trying to figure out what the ZCML was doing and how to mimic enough of that to set things up for my test... That's where the time was lost. I still steam up thinking about it. Why not provide helpful classes and functions, and make it obvious that they're there to support programmer code, not ZCML? (I noticed this with some of the odd little deferred factories around that get registered as utilities for things like vocabularies). Automate repetitive tasks with Python. I see something, theoretically, like this as a possibility: class AnnotationsAdapter(object): def __init__(self, annotationsKey, factory, assignName): self.annotationsKey = annotationsKey self.factory = factory self.assignName = assignName def __call__(self, context): annotations = IAnnotations(context) try: return annotations[self.annotationsKey] except KeyError: obj = self.factory() annotations[self.annotationsKey] = obj # to please security... zope.app.container.contained.contained( obj, context, self.assignName) return obj # In some other module from zope.annotations.helper import AnnotationsGetter FOO_KEY = 'foo.key' FooBarAnnotationsAdapter = AnnotationsAdapter(FOO_KEY, Foo, 'foo') And then in the zcml:adapter registration, or directly in the Python (either place above), declare the provides/adapts for this thing. I'm sure it can be done without requiring another ZCML directive. The bulk of my frustrations with Zope 3 have involved going down the rabbit hole of ZCML. Whether it's just trying to understand how something works, how I can provide a slightly different version of 'something' (ie - menu items with javascript actions), or trying to determine whether some erratic behavior is a bug on my part or Zope's, I inevitably end up in metaconfigure.py land. And it's the hardest code in Zope to read - even the metaprogramming in Interface and the sys._getframe tricks are easier to follow! So, please no. No more ZCML for automation. Please yes only for registration control. Please yes (or maybe) for global utility configuration like how to connect to an RDBMS (watching the Turbogears community start to realize that 'config.py' may not be a good thing because certain test and documentation tools will try to run it as Python and not set up its magic made me chuckle). But I beg you not to add to the ZCML pile because you had to copy and paste 12 lines of Python code. I think annotations are useful and I ran into having to write a similar bulk of code the other day - although my adapter and annotator had a larger separation (so 'zope:annotation' wouldn't have helped me anyways). I would argue that most situations requiring some sort of automation can be done by Plain Old Python Objects and Helpers and Plain Old Adapters and Utilities that can, wherever possible, be registered in "short form" . -- 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] a new zcml directive?
Martijn Faassen wrote: If I'm doing this quite a bit, this looks like something that would be better expressed in a... new ZCML directive (..waiting for the crowd to start flinging stones). A possibly valid direction we haven't discussed yet is to embrace ZCML's flexibility and make new high level directives often. For instance, every time I feel like I'm repeating myself in ZCML, maybe I should make a new high level directive to eliminate the repetition. The risk is that configuration ends up more magical, but maybe new tools can mitigate that risk. Thoughts? Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] a new zcml directive?
On Friday 10 March 2006 10:19, Martijn Faassen wrote: > What do people think? +1 We use this pattern for every annotation in SchoolTool and it gets old really quick. One argument that could be made is that the code in the function could be in the constructor. This is bad, because the __init__ method should not do any "writing" on other objects. 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] a new zcml directive?
Hi there, I notice a pattern in code that uses annotations that looks like this: class Foo(Persistent, Contained): implements(interfaces.IFoo) def getFoo(context): annotations = IAnnotations(context) try: return annotations[FOO_KEY] except KeyError: foo = Foo() annotations[FOO_KEY] = foo # to please security... zope.app.container.contained.contained( foo, context, 'foo') return foo # Convention to make adapter introspectable getFoo.factory = Foo If I'm doing this quite a bit, this looks like something that would be better expressed in a... new ZCML directive (..waiting for the crowd to start flinging stones). For instance, one that looks like this: where the factory actually points to whatever creates the real annotation (such as the Foo class in this case), not to the boilerplate to attach it to the proper object. The boilerplate would go away from my code, you could use the facility too without thought, and we'd all be happy. :) What do people think? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
