Announcements question

On 4 Nov 2009, at 21:50, Hernán Morales Durand wrote:

> Hi, I'm using AXAnnouncements but I suppose this question is valid
> for other implementations. In SASE (the "triggerEvent" event
> framework) one could subscribe an event for an object specifying an
> argument at registration time:
>
> eventSource
>   when: #eventName send: #aSelector to: anObject with: argument
>
> I've looked at Announcements and it seems this kind of registration
> isn't supported without using blocks. Am I right?
> Before getting into details I just want to check. What people do to
> specify an argument at registration time with Announcements?
>
> Cheers,
>
> Hernán

Your announcement is an object of your own design. You can put
parameters as instance variables in your announcement subclass.

The default implementation does not support the ability to send
methods to objects in the manner that you describe.
My Wandering Announcements package does have an enhancement to support
this,
it is available in the squeaksource.com/Jetsam repository.

Keith

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 4 Nov 2009, at 23:58, Hernán Morales Durand wrote:

> Hi Keith, thanks for your reply.
> I've tried your implementation a bit this way:

Ok, the package is SeaWA-Core,

First of all we add a double dispatch back to the Announcement,
enabling the Announcement subclass to be able to specialize announcing
policy. e.g. the default is to announce to all dependents, but you
might want to announce to all dependents that meet a certain criteria.

The class comment describes this as follows:
======
Unlike normal announcers which figure out what to announce to whom, as
much responsibility is given to each Announcement as possible so that
behaviour can be overriden completely for different scenarios.

When handling an announcement we double back and send #announceTo: to
the announcement itself to give it complete control, over what it does
before or after informing dependants. Its default behaviour is
#dependantsAnnounce . This allows an Announcement to replace the
behaviour of Announcer-#dependantsAnnounce: altogether if it wants to.
========

A second enhancement is to return the announcement from the invocation
of the trigger. Though I cant remember exactly why this is now.

=======
Triggering example: (we always return the original announcement)

theAnnouncement := self announcer announce: (SomeAnnouncement param:
arg1).
=======

Now here we come to the interesting bit.

===============
Subscriptions example:

self announcer on: SomeAnouncement do: [ :announcement | ...  ].
self announcer on: SomeAnouncement send: #tellMe: to: anObject.

Normally, the announcer is passed as the argument, however, each
announcement class defines  #args, so it can call a method that is not
expecting an Announcement as the parameter. This enables you to wire
up objects that were not designed with announcements in mind.

example trigger:
self announce: (HtmlUpdateAnnouncement on: html)

self announcer on: HtmlUpdateAnouncement send: #renderOn: to: anObject.

where:

HtmlUpdateAnnouncement-#args
^ Array with: html

=================


does that help?