[squeak-dev] Announcements?

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 <[hidden email]> wrote:
> Does anyone have a canonical site for Announcements handy? Is there a Squeak
> implementation?

http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&printTitle=Introducing_Announcements&entry=3310034894

http://source.lukas-renggli.ch/announcements.html



--
Damien Cassou
http://damiencassou.seasidehosting.st

Damien Cassou wrote:
> On Fri, Feb 27, 2009 at 5:24 PM, Andreas Raab <[hidden email]> wrote:
>> Does anyone have a canonical site for Announcements handy? Is there a Squeak
>> implementation?
>
> http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&printTitle=Introducing_Announcements&entry=3310034894
>
> http://source.lukas-renggli.ch/announcements.html

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.html 

Andreas Raab wrote: 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=Announcements%20Framework

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 pravi:

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



--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Andreas Raab wrote:
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á

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