2009/11/4 keith
<keith_hodges@yahoo.co.uk>
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?
Now I see the potential (the double dispatching is actually a scenario where making Announcements as classes does make more sense).
Although I can adapt the api with your approach, my issue is a situation where I want to keep the current interface (supporting Announcements transparently) and, at the tech level, setting up widgets inside containers which broadcast events both at asynchronous (with AJAX) and synchronous submission time, under this scenario, it is necessary to catch the contained arguments at subscription time for setting up its notification. Otherwise, if I choose to notify at signalling time, I have to select for all of them later which could be inefficient since they could be nested at many levels.
Anyway today, with an amazing lack of inspiration, I wrote an extension to the implementation to write something like:
������ eventSource
������ ������ subscribe: ( AnnouncementMockA with: argument )
�������������� send: #value:
�������������� to: anObject.
��
Just for the record, if someone needs this feature, it would be in the next SmallFaces release.
Cheers,