Folks -
I've been seeing references to the Announcements framework popping up in various places. From what I've seen it looks like it might be similar to an idea that I had never fully developed in Tweak. Unfortunately, googling for anything + "announcements" is basically impossible (lesson: When you choose the name of a framework, think about teh google!).
Does anyone have a canonical site for Announcements handy? Is there a Squeak implementation?
Cheers, - Andreas
On Fri, Feb 27, 2009 at 5:24 PM, Andreas Raab andreas.raab@gmx.de wrote:
Does anyone have a canonical site for Announcements handy? Is there a Squeak implementation?
http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&a...
http://source.lukas-renggli.ch/announcements.html
Damien Cassou wrote:
On Fri, Feb 27, 2009 at 5:24 PM, Andreas Raab andreas.raab@gmx.de wrote:
Does anyone have a canonical site for Announcements handy? Is there a Squeak implementation?
http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&a...
Wow. That is really nice. I was just playing with it and two things struck right away: How nice it is to be able to cross-reference events via Cmd-Shift-N (references to class) without being distracted by message names used to handle an event of the same name (i.e., self on: #mouseDown send: #mouseDown to: aMorph). Secondly, there is finally a way of documenting event types implicitly! (i.e., no more browse all senders of #signal: and try to see if there's one that looks about right)
Looks like a prime candidate for a nice little BPP[1] to me ;-)
Cheers, - Andreas
[1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/134256....
Andreas Raab wrote:
Damien Cassou wrote:
On Fri, Feb 27, 2009 at 5:24 PM, Andreas Raab andreas.raab@gmx.de wrote:
Does anyone have a canonical site for Announcements handy? Is there a Squeak implementation?
http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&a...
Wow. That is really nice. I was just playing with it and two things struck right away: How nice it is to be able to cross-reference events via Cmd-Shift-N (references to class) without being distracted by message names used to handle an event of the same name (i.e., self on: #mouseDown send: #mouseDown to: aMorph). Secondly, there is finally a way of documenting event types implicitly! (i.e., no more browse all senders of #signal: and try to see if there's one that looks about right)
Looks like a prime candidate for a nice little BPP[1] to me ;-)
Cheers,
- Andreas
see also:
http://lists.squeakfoundation.org/pipermail/seaside/2008-April/017540.html
as part of the thread:
http://lists.squeakfoundation.org/pipermail/seaside/2008-April/017417.html
Keith
Hi -
Thanks to everyone for all the info on announcements. For reference, I'd say the canonical URL is this one (as it links to the whole serious of posts about the topic):
http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Anno...
I spent quite a bit of the weekend playing with Announcements and I like it even more now. One thing that convinced me is that it is almost more like a pattern than a framework - you can implement it with minimal effort (I did it just by writing about 100loc total) but grow it to suit ones needs[1].
[1] One of the things I quickly found was that I wanted the subscription from #on:send:to: returned in order to be able to control whether it is client-owned (weak for the signaler) or not. Turned out that this is really just a minor modification which fits the model just fine.
One thing I am wondering about is whether anyone out there has been using Announcements for frameworks that have a larger number of events. The framework I applied it to ended up with some 30 events (the total number of classes in the framework is about 70, but it is event-heavy) which at first seemed excessive but it *is* the number of events that are being used so at least people can find out whether there is an event for a change of foo or not. In that sense my original intuition proved true (lots of classes but you do get to document the events in your system). I am curious how people feel about this proliferation of classes.
The other thing that using Announcements extensively will probably force is name spaces. It seems impossible for two frameworks not to have a "ValueChanged" event. The precise definition of which will likely differ (for example, where I've been using it, it is critical that the signaler gets passed along with it; but I am certain there are some places where people don't want to pay for that slot).
In any case, I think announcements are a great improvement over the usual pattern of using event names instead of objects. You should definitely give it a try the next time you consider using an event framework.
Cheers, - Andreas
Keith Hodges wrote:
Andreas Raab wrote:
Damien Cassou wrote:
On Fri, Feb 27, 2009 at 5:24 PM, Andreas Raab andreas.raab@gmx.de wrote:
Does anyone have a canonical site for Announcements handy? Is there a Squeak implementation?
http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&a...
Wow. That is really nice. I was just playing with it and two things struck right away: How nice it is to be able to cross-reference events via Cmd-Shift-N (references to class) without being distracted by message names used to handle an event of the same name (i.e., self on: #mouseDown send: #mouseDown to: aMorph). Secondly, there is finally a way of documenting event types implicitly! (i.e., no more browse all senders of #signal: and try to see if there's one that looks about right)
Looks like a prime candidate for a nice little BPP[1] to me ;-)
Cheers,
- Andreas
see also:
http://lists.squeakfoundation.org/pipermail/seaside/2008-April/017540.html
as part of the thread:
http://lists.squeakfoundation.org/pipermail/seaside/2008-April/017417.html
Keith
Andreas Raab pravi:
Thanks to everyone for all the info on announcements. For reference, I'd say the canonical URL is this one (as it links to the whole serious of posts about the topic):
http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Anno...
I spent quite a bit of the weekend playing with Announcements and I like it even more now. One thing that convinced me is that it is almost more like a pattern than a framework - you can implement it with minimal effort (I did it just by writing about 100loc total) but grow it to suit ones needs[1].
[1] One of the things I quickly found was that I wanted the subscription from #on:send:to: returned in order to be able to control whether it is client-owned (weak for the signaler) or not. Turned out that this is really just a minor modification which fits the model just fine.
One thing I am wondering about is whether anyone out there has been using Announcements for frameworks that have a larger number of events.
The VW Pollock/Widgetry GUI framework (now abandoned) uses Announcements for all UI events. Announcements were actually designed to support this framework. This proves that Announcements are capable to support environments with large amount of events.
We are also using Announcements in Aida/Web framework (VW port) to signal events to other loosely coupled systems/plugins like BiArt/BPM (for executing business processes). Aida sends event for every request executing down its path (view shown, action triggered).
Business processes are also all about events, while on the other side the web app is also full of events. Not to tie those two things too closely is then achieved with event mechanism like Announcements.
Janko
The framework I applied it to ended up with some 30 events (the total number of classes in the framework is about 70, but it is event-heavy) which at first seemed excessive but it *is* the number of events that are being used so at least people can find out whether there is an event for a change of foo or not. In that sense my original intuition proved true (lots of classes but you do get to document the events in your system). I am curious how people feel about this proliferation of classes.
The other thing that using Announcements extensively will probably force is name spaces. It seems impossible for two frameworks not to have a "ValueChanged" event. The precise definition of which will likely differ (for example, where I've been using it, it is critical that the signaler gets passed along with it; but I am certain there are some places where people don't want to pay for that slot).
In any case, I think announcements are a great improvement over the usual pattern of using event names instead of objects. You should definitely give it a try the next time you consider using an event framework.
Cheers,
- Andreas
Andreas Raab wrote:
Hi -
Thanks to everyone for all the info on announcements. For reference, I'd say the canonical URL is this one (as it links to the whole serious of posts about the topic):
http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Anno...
I spent quite a bit of the weekend playing with Announcements and I like it even more now. One thing that convinced me is that it is almost more like a pattern than a framework - you can implement it with minimal effort (I did it just by writing about 100loc total) but grow it to suit ones needs[1].
[1] One of the things I quickly found was that I wanted the subscription from #on:send:to: returned in order to be able to control whether it is client-owned (weak for the signaler) or not. Turned out that this is really just a minor modification which fits the model just fine.
One thing I am wondering about is whether anyone out there has been using Announcements for frameworks that have a larger number of events.
I'm using Announcements with my webapp and I have 40 classes and about 25 distinct events. No problem until now either in performance or in code readability. Also, the fact that the announcement can convey real objects it is really the best thing of anything.
Miguel Cobá
The framework I applied it to ended up with some 30 events (the total number of classes in the framework is about 70, but it is event-heavy) which at first seemed excessive but it *is* the number of events that are being used so at least people can find out whether there is an event for a change of foo or not. In that sense my original intuition proved true (lots of classes but you do get to document the events in your system). I am curious how people feel about this proliferation of classes.
The other thing that using Announcements extensively will probably force is name spaces. It seems impossible for two frameworks not to have a "ValueChanged" event. The precise definition of which will likely differ (for example, where I've been using it, it is critical that the signaler gets passed along with it; but I am certain there are some places where people don't want to pay for that slot).
In any case, I think announcements are a great improvement over the usual pattern of using event names instead of objects. You should definitely give it a try the next time you consider using an event framework.
Cheers,
- Andreas
Keith Hodges wrote:
Andreas Raab wrote:
Damien Cassou wrote:
On Fri, Feb 27, 2009 at 5:24 PM, Andreas Raab andreas.raab@gmx.de wrote:
Does anyone have a canonical site for Announcements handy? Is there a Squeak implementation?
http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&a...
Wow. That is really nice. I was just playing with it and two things struck right away: How nice it is to be able to cross-reference events via Cmd-Shift-N (references to class) without being distracted by message names used to handle an event of the same name (i.e., self on: #mouseDown send: #mouseDown to: aMorph). Secondly, there is finally a way of documenting event types implicitly! (i.e., no more browse all senders of #signal: and try to see if there's one that looks about right)
Looks like a prime candidate for a nice little BPP[1] to me ;-)
Cheers,
- Andreas
see also:
http://lists.squeakfoundation.org/pipermail/seaside/2008-April/017540.html
as part of the thread:
http://lists.squeakfoundation.org/pipermail/seaside/2008-April/017417.html
Keith
Andreas Raab wrote:
One thing I am wondering about is whether anyone out there has been using Announcements for frameworks that have a larger number of events. The framework I applied it to ended up with some 30 events (the total number of classes in the framework is about 70, but it is event-heavy) which at first seemed excessive but it *is* the number of events that are being used so at least people can find out whether there is an event for a change of foo or not. In that sense my original intuition proved true (lots of classes but you do get to document the events in your system). I am curious how people feel about this proliferation of classes.
I used Announcements in OmniBrowser. There are 18 Announcement classes in my image, and maybe a few more floating around in other packages. I also use the pattern for another purpose, Command, which is the OmniBrowser mechanism for populating menus and buttons. The "browse senders of..." menu item, for example, is created by an instance of OBCmdBrowseSenders. In my image, there are 172 subclasses of OBCommand, and dozens more in packages I don't have loaded.
At first I was a bit skeptical about the explosion of classes. Even while I was implementing it, I thought of it as a bit of a hack - practical maybe, but inelegant. Since then I've decided I really like it. There *is* something inelegant there - too many named entities - but it's extremely easy to understand how Commands work and implement new ones.
The other thing that using Announcements extensively will probably force is name spaces. It seems impossible for two frameworks not to have a "ValueChanged" event. The precise definition of which will likely differ (for example, where I've been using it, it is critical that the signaler gets passed along with it; but I am certain there are some places where people don't want to pay for that slot).
Yeah. OmniBrowser already used 'OB' as a class name prefix, but even so, I prefixed command names with 'OBCmd'. I haven't run into any conflicts yet, but it feels cleaner that way.
In any case, I think announcements are a great improvement over the usual pattern of using event names instead of objects. You should definitely give it a try the next time you consider using an event framework.
I second this endorsement. Implementing Announcements (and Commands) for OmniBrowser vastly simplified things. This was a few years ago - here's what I wrote about it at the time:
http://www.wiresong.ca/air/articles/2006/06/11/announcements
Colin
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Colin Putney -
Damien Cassou -
Janko Mivšek -
Keith Hodges -
Miguel Enrique Cobá Martínez