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
