[squeak-dev] 2 ports of Announcements ?

There seems to be two different port of Announcement for Squeak :
- http://source.lukas-renggli.ch/announcements.html
- http://www.squeaksource.com/AXAnnouncements.html

Which one should i use ?

--                                                         oooo
Serge Stinckwich                                         OOOOOOOO
http://doesnotunderstand.org/                            OOESUGOO
Smalltalkers do: [:it | All with: Class, (And love: it)]  oooooo
                                                           \  /
                                                            ##

>  There seems to be two different port of Announcement for Squeak :
>  - http://source.lukas-renggli.ch/announcements.html
>  - http://www.squeaksource.com/AXAnnouncements.html
>
>  Which one should i use ?

I guess you just create your own ;-)

My code is not really a port. It just adds some extra features to the
implementation that is found in OB. The concept of announcements is
really simple. A basic implementation doesn't consist of more than a
couple of methods in a few classes.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Serge Stinckwich wrote:
>
> There seems to be two different port of Announcement for Squeak :
> - http://source.lukas-renggli.ch/announcements.html
> - http://www.squeaksource.com/AXAnnouncements.html
>
> Which one should i use ?
>
You could give my new WanderingAnnouncements code a try, depends upon
your application of course.

The idea of wandering announcements is that they can have some idea of
the physical structure of your model and can route themselves accordingly.

I append my design sketches...

best tregards

Keith

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


Further to the announcements debate.... here is a code design overview
for your considered appraisal.

"Wandering Announcements" inSeaside.

I am throwing some code together so there is some untested code
available in

Installer ss project: 'Jetsam'; install: 'Sea28WA'.

best regards

Keith

======
the following is from posts to the seaside list with some corrections
======

(This design is based upon Lukas' simple Announcements framework as a
starting point)

Whereas Announcements are often used with a centralized Announcer,
Wandering announcements may
look for someone to respond to their message in the given surroundings.
They may "bubble up" a component hierarchy, or interrogate siblings, or
decorations as they wish.

Each WAComponent in seaside is a node in this communications network.
Nodes function as potential announcers, and as a source of potential
routes for wandering announcements to follow.

Routing is provided by #ann* methods, which are private to the
Announcers for use by instances of WanderingAnnouncements, no one else
should call them.  e.g. #annParent #annSiblingsIn: [ :siblings | ....
].  #annChildrenIn: [ :children | .... ].

Unlike the original framework in which Announcements allow the Announcer
to figure out what to announce to whom, as much responsibility passed
over to each Announcement as is possible so that behaviour can be
overridden completely for different needs.

I.e. when handling an announcement we double back #announceTo: to the
announcement itself to give it complete control, over what it does
before or after informing dependants.

Triggering example: (we always return the original announcement)

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

Subscriptions example:

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

Normally, the announcer is passed as the argument to the
Block/MessageSend, however, each announcement implements #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

=============
Wandering around
=============

Example... we have a list of items, and one of the items in the list has
just been clicked. It would like to inform the current selection, one of
its "siblings" that it is being de-selected. I say siblings, because it
doesnt really know where in the world it is.

The nature of this Seaside component world, is that there are some
objects that might be naturally considered to be siblings, so these are
automatically traversed by the announcement WALookupSideways which we
can subclass. But we can also register other objects/components which
also respond to a sideways query, see below:

Client Code:

foundItem := ((aComponent announce:  (WALookupSideways selector:
#isSelected)) detect: [ :found | found isSelected ]) result.
foundItem ifNotNil: [ foundItem deselect ].

Walking through this example...  we give our announcement,
WALookupSideways, a selector to look out for. Every object in its
wandering that responds to the selector is passed into the detect block.
When the result of the detect block is true, wandering stops, and the
announcer is returned (remember we always return the announcement). We
send #result to the announcement to obtain the found item.

If there is an object that is not in the search path that would like to
participate, it can be registered like so.

aComponent announcer on: WALookupSideways do: [ :announcement |
announcement query: someObject ]

I had expressed the idea that currently a WAComponent was like an
infant, unable to articulate its needs, and unaware of its place in the
world. In the Wandering Announcements model we give each component the
ability to specify what it does know about the world. That is all it is
doing, it is just saying, what the world around it is like, what is
above, below to the left and to the right.

It is up to wandering announcements to make use of these relationships
for routing events. Child components do not explicitly know anything
about their parents. But they do know that they may have a parent, or a
brother, and they can shout, oi Dad, oi Bro', and potentially get a
response.

Components implement:

#annParent

#annChildrenIn: block

and hence:

#annSiblingsIn: block

Wandering announcements use these as implicit relationships over which
to wander. Note however that these published relationships need not be
related to the actual component hierarchy.

A chess board, could publish each of its 64 squares as annChildrenIn:
even though in actual fact, it is implemented by 8 x
WAChessBoardRowComponents. This would allow each of the squares to
announce to all 63 of its siblings, even though in the actual component
hierarchy each square only has 7 direct siblings.

There is nothing stopping additional objects that are not in the right
place at the right time to be included as a sibling, they are simply
subscribed to the announcements meant for siblings.

There is nothing stopping more spatial relationships being defined, such
as..

#annBoardSquares

or

#annItemsToMyLeft

or

#annTrainTrackNextPiece

A chess board, has one implementation, a monopoly board has an entirely
different implementation. However a "white knight" could be equally at
home on either and can do things such as.

self announce: (HighlightValidMoves for: self)

I think this preserves the principles that Children dont know explicitly
about their parents, but now they have permission to ask questions of
their surroundings.

ok, now to test this all out!

Keith




Keith






















_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside