Re: [Zope3-dev] Re: Contained events interface inheritance order
Florent Guillaume wrote: Well I don't want to appear to defend Apple Mail too much here, but splitting a URL after a / can be seen as a natural location. And in any case this wouldn't be a problem if Mozilla coders weren't lazy :-) (decoding rfc3676 (which is nearly 2 years old now) is trivial when you already do rfc2646 (format=flowed)) Or just buy a Mac ;) Florent don't rush for the mac yet: -) this should be in one of the latest thunderbird versions. https://bugzilla.mozilla.org/show_bug.cgi?id=231701 /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Contained events interface inheritance order
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: > On 30 Nov 2005, at 17:04, Jim Fulton wrote: > >> Florent Guillaume wrote: >> >>> On 30 Nov 2005, at 13:17, Jim Fulton wrote: >>> (Is there some reason for the urls you give to have spaces in them? It makes them harder to follow. It appears that this is a mac thing. It's rather annoying.) >>> >>> This is the delsp parameter of rfc3676, which apparently only Apple >>> Mail implements, I've no idea why the other mailers haven't >>> followed suit. >> >> >> Perhaps because it is really annoying? > > > Only because Mozilla doesn't implement that RFC :-). Otherwise you'd be > able to see perfectly wrapped messages and non-broken URLs. I don't think RFC 3676 intends to wrap URLs; it is about signalling "soft line breaks", which aren't normally found within tokens: - From http://www.faqs.org/rfcs/rfc3676.html, section 4.2 >Regardless of which technique is used, a generating agent SHOULD NOT >insert a space in an unnatural location, such as into a word (a >sequence of printable characters, not containing spaces, in a >language/coded character set in which spaces are common). If faced >with such a word which exceeds 78 characters (but less than 998 >characters, the [SMTP] limit on line length), the agent SHOULD send >the word as is and exceed the 78-character limit on line length. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDjfuP+gerLs4ltQ4RAnSsAKCWmnkbvgJ/VRjScbw+iCP7RGZKAgCfa5AW 0NJ6zfkU/uo6jHlU7ggUl2A= =pabh -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Contained events interface inheritance order
On 30 Nov 2005, at 20:20, Tres Seaver wrote: Florent Guillaume wrote: On 30 Nov 2005, at 17:04, Jim Fulton wrote: Florent Guillaume wrote: On 30 Nov 2005, at 13:17, Jim Fulton wrote: (Is there some reason for the urls you give to have spaces in them? It makes them harder to follow. It appears that this is a mac thing. It's rather annoying.) This is the delsp parameter of rfc3676, which apparently only Apple Mail implements, I've no idea why the other mailers haven't followed suit. Perhaps because it is really annoying? Only because Mozilla doesn't implement that RFC :-). Otherwise you'd be able to see perfectly wrapped messages and non-broken URLs. I don't think RFC 3676 intends to wrap URLs; it is about signalling "soft line breaks", which aren't normally found within tokens: - From http://www.faqs.org/rfcs/rfc3676.html, section 4.2 Regardless of which technique is used, a generating agent SHOULD NOT insert a space in an unnatural location, such as into a word (a sequence of printable characters, not containing spaces, in a language/coded character set in which spaces are common). If faced with such a word which exceeds 78 characters (but less than 998 characters, the [SMTP] limit on line length), the agent SHOULD send the word as is and exceed the 78-character limit on line length. Well I don't want to appear to defend Apple Mail too much here, but splitting a URL after a / can be seen as a natural location. And in any case this wouldn't be a problem if Mozilla coders weren't lazy :-) (decoding rfc3676 (which is nearly 2 years old now) is trivial when you already do rfc2646 (format=flowed)) Or just buy a Mac ;) Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Contained events interface inheritance order
Florent Guillaume wrote: I'm surprised no-one has commented on this. Jim, you did the last work on this, could you tell me what you think? Sorry, I missed the original message. Replying now. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.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] Re: Contained events interface inheritance order
Hi > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Florent Guillaume > Sent: Wednesday, November 30, 2005 2:00 AM > To: zope3-dev@zope.org > Subject: [Zope3-dev] Re: Contained events interface inheritance order > > I'm surprised no-one has commented on this. Jim, you did the > last work > on this, could you tell me what you think? > > Florent > > Florent Guillaume wrote: > > Today the contained events interfaces are: > > class IObjectMovedEvent(IObjectEvent) > > class IObjectAddedEvent(IObjectMovedEvent) > > class IObjectRemovedEvent(IObjectMovedEvent) I dont' know if this affect the events itself but there is also a problem in the ObjectMover. If you use the ObjectMover from copypastemove on IDependable (registered) objects, it's not possible to move a object because of the order the move process is implemented. --- target[new_name] = obj del container[orig_name] if the ObjectAdded Event will add a dependency to the object we can't delete them in the container. If this should be fixed, I'm not sure if the ObjectMover should copy dependable objects, then the order should be: --- del container[orig_name] target[new_name] = obj This means the events order in this usecase looks like: IObjectRemovedEvent IObjectAddedEvent IObjectMovedEvent Where the IObjectMovedEvent notifies about the sucessful move. Anyway, add a object to a container where is at the same time in a second container is a bad idea in my point of view. What do you think? Regards Roger Ineichen > > From the archives I can find this was decided after: > > http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ > > SimplifyObjectLifecycleAndLocationEvents > > but without motivation for this part. I'm still looking for the > > motivation... > > > > Before that proposal, the hierarchy was: > > class IObjectAddedEvent(IObjectEvent) > > class IObjectRemovedEvent(IObjectEvent) > > class IObjectMovedEvent(IObjectAddedEvent, IObjectRemovedEvent) > > > > I contend that this second hierarchy is much more useful to > deal with. > > The arguments I have are in the use cases explained in: > > http://blogs.nuxeo.com/sections/blogs/florent_guillaume/ > > 2005_11_08_events-in-zope-2-9 > > where you can see the hoops one has to go through to react > to objects > > being created, deleted or moved with the current event hierarchy. > > > > I'd like to know what non-framework use cases people have > today with > > the current event interfaces hierarchy, and if they really > find it more > > useful than the old one. > > > > If not, or if the use cases are borderline, I'd like to > propose that > > the hierarchy be moved back to the second form. This would > have to go > > through a deprecation phase, I'm not sure exactly how, but > if there's > > consensus we can find a way. > > > > Myself I consider the current hierarchy to be a design bug. > > > > Florent > > > > > -- > Florent Guillaume, Nuxeo (Paris, France) Director of R&D > +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Contained events interface inheritance order
I'm surprised no-one has commented on this. Jim, you did the last work on this, could you tell me what you think? Florent Florent Guillaume wrote: Today the contained events interfaces are: class IObjectMovedEvent(IObjectEvent) class IObjectAddedEvent(IObjectMovedEvent) class IObjectRemovedEvent(IObjectMovedEvent) From the archives I can find this was decided after: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ SimplifyObjectLifecycleAndLocationEvents but without motivation for this part. I'm still looking for the motivation... Before that proposal, the hierarchy was: class IObjectAddedEvent(IObjectEvent) class IObjectRemovedEvent(IObjectEvent) class IObjectMovedEvent(IObjectAddedEvent, IObjectRemovedEvent) I contend that this second hierarchy is much more useful to deal with. The arguments I have are in the use cases explained in: http://blogs.nuxeo.com/sections/blogs/florent_guillaume/ 2005_11_08_events-in-zope-2-9 where you can see the hoops one has to go through to react to objects being created, deleted or moved with the current event hierarchy. I'd like to know what non-framework use cases people have today with the current event interfaces hierarchy, and if they really find it more useful than the old one. If not, or if the use cases are borderline, I'd like to propose that the hierarchy be moved back to the second form. This would have to go through a deprecation phase, I'm not sure exactly how, but if there's consensus we can find a way. Myself I consider the current hierarchy to be a design bug. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
