Hi everyone, I just tried to create a catalog for an annotation and noticed that it does not get filled. Digging around in the zope.annotation package, I noticed that the zope.annotation package does not send out any object events. This sucks. ;-) Thus I propose: - Add ObjectCreatedEvent event notification to zope.annotation factory call. - Add ObjectAddedEvent to attribute annotations __setitem__. - Add ObjectRemovedEvent to attribute annotations __delitem__. This would mimic the behavior of the other containers. the downside is that we have 2 new dependencies, zope.event and zope.lifecycleevent, both of which are acceptable in my opinion. Comments? Silence is consent as always. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
On Tue, Jul 15, 2008 at 12:30 PM, Stephan Richter <srichter@cosmos.phy.tufts.edu> wrote:
Thus I propose:
- Add ObjectCreatedEvent event notification to zope.annotation factory call.
By this, I presume you mean the stuff in zope.annotation.factory; is that right? In our group, we've decided to avoid that machinery. It causes the separation between data and code to become excessively blurred. I'd love to see that factory machinery become unused. I definitely consider it unusable. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Tuesday 15 July 2008, Fred Drake wrote:
On Tue, Jul 15, 2008 at 12:30 PM, Stephan Richter
<srichter@cosmos.phy.tufts.edu> wrote:
Thus I propose:
- Add ObjectCreatedEvent event notification to zope.annotation factory call.
By this, I presume you mean the stuff in zope.annotation.factory; is that right?
Yes.
In our group, we've decided to avoid that machinery. It causes the separation between data and code to become excessively blurred. I'd love to see that factory machinery become unused. I definitely consider it unusable.
I use it all the time. I think it makes development a lot easier. In fact, this came out of the ST project, where we constantly repeated this sort of code. BTW, I really do not understand how it blurs the separation of code and data. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter wrote:
On Tuesday 15 July 2008, Fred Drake wrote:
On Tue, Jul 15, 2008 at 12:30 PM, Stephan Richter
<srichter@cosmos.phy.tufts.edu> wrote:
Thus I propose:
- Add ObjectCreatedEvent event notification to zope.annotation factory call. By this, I presume you mean the stuff in zope.annotation.factory; is that right?
Yes.
In our group, we've decided to avoid that machinery. It causes the separation between data and code to become excessively blurred. I'd love to see that factory machinery become unused. I definitely consider it unusable.
I use it all the time. I think it makes development a lot easier.
I agree.
In fact, this came out of the ST project, where we constantly repeated this sort of code.
Not that it matters much, but I think it was Martijn Faassen who wrote it.
BTW, I really do not understand how it blurs the separation of code and data.
Me neither.
On Wednesday 16 July 2008, Philipp von Weitershausen wrote:
this came out of the ST project, where we constantly repeated this sort of code.
Not that it matters much, but I think it was Martijn Faassen who wrote it.
... who worked on ST at the time and saw this pattern there. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter wrote:
On Wednesday 16 July 2008, Philipp von Weitershausen wrote:
this came out of the ST project, where we constantly repeated this sort of code. Not that it matters much, but I think it was Martijn Faassen who wrote it.
... who worked on ST at the time and saw this pattern there.
Yes, I forget the details, but I do recall this change being schooltool-inspired or driven. Obviously I don't understand Fred's rather strongly worded objections either. :) In Grok, we have grok.Adapter and grok.Annotation. grok.Annotation is, I think, easy to explain: it's an adapter that actually persists its own data. The factory pattern supports this. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephan Richter wrote:
Hi everyone,
I just tried to create a catalog for an annotation and noticed that it does not get filled. Digging around in the zope.annotation package, I noticed that the zope.annotation package does not send out any object events. This sucks. ;-)
Thus I propose:
- Add ObjectCreatedEvent event notification to zope.annotation factory call.
- Add ObjectAddedEvent to attribute annotations __setitem__.
- Add ObjectRemovedEvent to attribute annotations __delitem__.
This would mimic the behavior of the other containers. the downside is that we have 2 new dependencies, zope.event and zope.lifecycleevent, both of which are acceptable in my opinion.
Comments? Silence is consent as always.
I must be missing something: why would you catalog annoations as though they were separate content objects? The entire point of annotations was to be "meta" about some other content object. - -1 to any change which encourages abusing them to look like "items" in the target object as a container. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfN90+gerLs4ltQ4RAiusAJ0dSzChnQme4ncb79I52wyVY7nkDQCgizOK rmzBPUOJtZgQiTmpswogzDc= =Acg2 -----END PGP SIGNATURE-----
On Tuesday 15 July 2008, Tres Seaver wrote:
Comments? Silence is consent as always.
I must be missing something: why would you catalog annoations as though they were separate content objects? The entire point of annotations was to be "meta" about some other content object.
Right, but annotations are still content in their own right. And we fire events that are specific to annotations all the time, for example in workflow instances.
-1 to any change which encourages abusing them to look like "items" in the target object as a container.
It does not have to be like a container. It could be: IAnnotationAdded(object, key, annotation) Right now, I have no hook that allows me to do something else after I added a new annotation for an object. Events are designed to allow expanding the system without touching the original code. And that's what I want to do. We do it in all the other packages of Zope 3. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
On Tue, Jul 15, 2008 at 2:28 PM, Stephan Richter <srichter@cosmos.phy.tufts.edu> wrote:
Right, but annotations are still content in their own right. And we fire events that are specific to annotations all the time, for example in workflow instances.
I agree that it's reasonable to fire some event when an annotation is added; I don't think it should provide to zope.app.container.interfaces.IObjectAddedEvent, because that is about the containment hierarchy. It *might* be reasonable for the factory machinery to trigger an ObjectCreatedEvent for the new object; I've little opinion on that. It *is* reasonable for the IAnnotations adapters to generate a specific annotation-added event when an annotation is added. There are probably a whole bunch of other hooks needed to get all that working with catalogs, and I'd hate to see more magical subscribers added to make that happen; the existing subscribers that deal with catalogs and int id assignments are already excessively implicit, and often need to be suppressed for large applications. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Tuesday 15 July 2008, Fred Drake wrote:
It *is* reasonable for the IAnnotations adapters to generate a specific annotation-added event when an annotation is added. There are probably a whole bunch of other hooks needed to get all that working with catalogs, and I'd hate to see more magical subscribers added to make that happen; the existing subscribers that deal with catalogs and int id assignments are already excessively implicit, and often need to be suppressed for large applications.
No, the catalog hookup would be app specific. I am not proposing to add more code other than the event itself. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Hi
Betreff: Re: [Zope-dev] Re: No events in zope.annotation
On Tue, Jul 15, 2008 at 2:28 PM, Stephan Richter <srichter@cosmos.phy.tufts.edu> wrote:
Right, but annotations are still content in their own right. And we fire events that are specific to annotations all the time, for example in workflow instances.
I agree that it's reasonable to fire some event when an annotation is added; I don't think it should provide to zope.app.container.interfaces.IObjectAddedEvent, because that is about the containment hierarchy.
It *might* be reasonable for the factory machinery to trigger an ObjectCreatedEvent for the new object; I've little opinion on that.
It *is* reasonable for the IAnnotations adapters to generate a specific annotation-added event when an annotation is added. There are probably a whole bunch of other hooks needed to get all that working with catalogs, and I'd hate to see more magical subscribers added to make that happen; the existing subscribers that deal with catalogs and int id assignments are already excessively implicit, and often need to be suppressed for large applications.
I agree on that. I recommend everybody to use it's own custom event handling in complexer applications. And avoid every event which is offered by Zope3 as default. The speedup can be hugh if you select carfully what really happens! Regards Roger Ineichen
-Fred
-- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephan Richter wrote:
On Tuesday 15 July 2008, Tres Seaver wrote:
Comments? Silence is consent as always. I must be missing something: why would you catalog annoations as though they were separate content objects? The entire point of annotations was to be "meta" about some other content object.
Right, but annotations are still content in their own right.
Not by design, anyway, although you might be using them that way. They aren't traversable (by default), nor are they "located". Why not just fire the event in whatever application code you are using to stash the annoation? However this works out, any events fired should not be of the same type as events that "normal" content emits.
And we fire events that are specific to annotations all the time, for example in workflow instances.
The events are not *about* the annotation: they are about the state transition. In fact, one way to implement workflow history would be to create and add the annotation *in the subscriber* to the state transition event.
-1 to any change which encourages abusing them to look like "items" in the target object as a container.
It does not have to be like a container. It could be:
IAnnotationAdded(object, key, annotation)
Right now, I have no hook that allows me to do something else after I added a new annotation for an object.
How likely is it that such a hook is generically useful (compared to just publishing the event, or doing the work, in the code which is adding your custom annotations?) It sounds as though you are creating a framework for which such events are meaningful, but I would be extremely surprised if that framework expected "foreign code to add its annotations.
Events are designed to allow expanding the system without touching the original code. And that's what I want to do. We do it in all the other packages of Zope 3.
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfSx3+gerLs4ltQ4RAkYkAKDMNcAcPF9uorwX3rXFC8MlonyCcwCfUyri f3nMn9kLcdQS1l6XQBC0vms= =vFd6 -----END PGP SIGNATURE-----
Stephan Richter wrote:
Hi everyone,
I just tried to create a catalog for an annotation and noticed that it does not get filled. Digging around in the zope.annotation package, I noticed that the zope.annotation package does not send out any object events. This sucks. ;-)
Thus I propose:
- Add ObjectCreatedEvent event notification to zope.annotation factory call.
+0
- Add ObjectAddedEvent to attribute annotations __setitem__.
- Add ObjectRemovedEvent to attribute annotations __delitem__.
-1. As Fred said, these events are specific to containers (as in IContainer). IAnnotation adapters aren't containers and annotation objects aren't contained in them (as in IContained).
On Wednesday 16 July 2008, Philipp von Weitershausen wrote:
- Add ObjectAddedEvent to attribute annotations __setitem__.
- Add ObjectRemovedEvent to attribute annotations __delitem__.
-1. As Fred said, these events are specific to containers (as in IContainer). IAnnotation adapters aren't containers and annotation objects aren't contained in them (as in IContained).
I agree. I realized only later that those events are defined in the zope.app.container package. In this case I would just create new annotation-specific events based on ObjectEvent, which is defined in zope.component, and zope.component is already a dependency. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
On Wed, Jul 16, 2008 at 10:26 AM, Stephan Richter <srichter@cosmos.phy.tufts.edu> wrote:
I agree. I realized only later that those events are defined in the zope.app.container package. In this case I would just create new annotation-specific events based on ObjectEvent, which is defined in zope.component, and zope.component is already a dependency.
Hmm. Would these be fired by the IAnnotations adapter or by the factory? There might be some interesting tradeoffs there. Many annotations are just simple data types (strings, tuples, dictionaries); those can be used with object events, but it seems a little non-intuitive. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Wednesday 16 July 2008, Fred Drake wrote:
On Wed, Jul 16, 2008 at 10:26 AM, Stephan Richter
<srichter@cosmos.phy.tufts.edu> wrote:
I agree. I realized only later that those events are defined in the zope.app.container package. In this case I would just create new annotation-specific events based on ObjectEvent, which is defined in zope.component, and zope.component is already a dependency.
Hmm. Would these be fired by the IAnnotations adapter or by the factory? There might be some interesting tradeoffs there. Many annotations are just simple data types (strings, tuples, dictionaries); those can be used with object events, but it seems a little non-intuitive.
I do not think that I have a single annotation that is a simple type. I cannot even think of a quick example where any of the Zope 3 core packages have/use simple type annotations. But I agree. The system supports simple type and that is one of the use cases. While I originally wanted to add at least 2 of the events to the IAnnotations adapter itself, I agree with you that the overhead penalty might be too severe. With this in mind, I am modifying my proposal to add 2 event notifications to the factory only to produce a function like this (it is the result of calling the annotation factory): def myFactory(context): key = '...' annotations = zope.annotation.interfaces.IAnnotations(context) try: result = annotations[key] except KeyError: result = Approval() zope.event.notify(zope.lifecycleevent.ObjectCreatedEvent(result)) annotations[key] = result located_result = zope.location.location.located(result, context, key) zope.event.notify(AnnotationAddedEvent(located_result)) return located_result I am torn whether the created event should be a annotation specific or not, because an object is not an annotation until it has been added as one. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
On Wed, Jul 16, 2008 at 10:45 AM, Stephan Richter <srichter@cosmos.phy.tufts.edu> wrote:
But I agree. The system supports simple type and that is one of the use cases. While I originally wanted to add at least 2 of the events to the IAnnotations adapter itself, I agree with you that the overhead penalty might be too severe.
I don't think I said anything about a penalty on this, though that could certainly be an issue. I doubt it really is, though.
With this in mind, I am modifying my proposal to add 2 event notifications to the factory only to produce a function like this (it is the result of calling the annotation factory):
My preference would be that these events would not be specific to the factory, keeping the model clean.
I am torn whether the created event should be a annotation specific or not, because an object is not an annotation until it has been added as one.
The created event should not be annotation-specific, for the reason you cite -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
Previously Stephan Richter wrote:
On Wednesday 16 July 2008, Fred Drake wrote:
On Wed, Jul 16, 2008 at 10:26 AM, Stephan Richter
<srichter@cosmos.phy.tufts.edu> wrote:
I agree. I realized only later that those events are defined in the zope.app.container package. In this case I would just create new annotation-specific events based on ObjectEvent, which is defined in zope.component, and zope.component is already a dependency.
Hmm. Would these be fired by the IAnnotations adapter or by the factory? There might be some interesting tradeoffs there. Many annotations are just simple data types (strings, tuples, dictionaries); those can be used with object events, but it seems a little non-intuitive.
I do not think that I have a single annotation that is a simple type. I cannot even think of a quick example where any of the Zope 3 core packages have/use simple type annotations.
FWIW none of my code uses anything other than simple types for annotations. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Hi Stephan
Betreff: Re: [Zope-dev] Re: No events in zope.annotation
[...]
I do not think that I have a single annotation that is a simple type. I cannot even think of a quick example where any of the Zope 3 core packages have/use simple type annotations.
FWIW none of my code uses anything other than simple types for annotations.
Even worse, I store objects in the annotation wich are added to a real IContainer as items somewhere else. This objects are created, added etc. already in the other container and provide locations from there. How can you skip events for this referenced objects? I think a event ware PrincipalAnnotation should be a second option and the existing should stay without events. Or probably add a property like: principalAnnotation.notifyAddedEvent = True Or implement a pattern which allows to notify events for specific interfaces if items get added. I'm fine with everything if you make sure that you don't notify events for my referenced objects. At least not with default events which hook up existing subscribers. Regards Roger Ineichen
Wichert.
-- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
On Wed, Jul 16, 2008 at 11:33 AM, Roger Ineichen <dev@projekt01.ch> wrote:
Even worse, I store objects in the annotation wich are added to a real IContainer as items somewhere else. This objects are created, added etc. already in the other container and provide locations from there.
Only the factory should generate object created events; it sounds like you're not using that. The added/replaced/removed events should not be the containment events at all, though making them object events should be acceptable. I don't see any need for a way to suppress them, since they shouldn't trigger any subscribers for the normal containment events. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Wed, Jul 16, 2008 at 11:46 AM, Fred Drake <fdrake@gmail.com> wrote:
I don't see any need for a way to suppress them, since they shouldn't trigger any subscribers for the normal containment events.
Based on some discussion here, I realize that my position may not be terribly clear. Just to make myself clear: - Do what you want with the factory; I don't want it used (directly or indirectly) from the ZC codebase (not that I get to set policy or anything). - I think it's reasonable for an IAnnotations provider to generate annotations-related events for add/replace/remove operations. - I see no reason that the default IAnnotations implementations generate events; we want to avoid firing events all over the place just so we can ignore them. The last, in particular, needed to be stated explicitly. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Wed, Jul 16, 2008 at 10:26 AM, Stephan Richter <srichter@cosmos.phy.tufts.edu> wrote:
I agree. I realized only later that those events are defined in the zope.app.container package. In this case I would just create new annotation-specific events based on ObjectEvent, which is defined in
I'm also assuming that there will be a full set of events: - added - replaced - removed I suspect this is what you mean, though we've been mostly referring to the added event. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Wednesday 16 July 2008, Fred Drake wrote:
I suspect this is what you mean, though we've been mostly referring to the added event.
Right. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
participants (7)
-
Fred Drake -
Martijn Faassen -
Philipp von Weitershausen -
Roger Ineichen -
Stephan Richter -
Tres Seaver -
Wichert Akkerman