Hi everyone - I’ve always thought the article on announcements many years ago
was very cool - and we don’t seem to use them as much as we could (but equally
they aren’t a panacea to be overused everywhere either - and they do get used
in Pharo to some extent).
Anyway, I’ve been playing around with CodeParadise (CP is a very cool project,
and Erik is very supportive and thinking about how to write web apps a
different way… I’m fascinated),
And - CP uses announcements as mechanism to send events from the View Client
(in a web browser) to a Presenter on the server (which makes total sense).
In taking things for a spin, I hit an interesting problem on how in a web
component world, you should display a spelling test of words -
e.g. SpellingTest — has many —> SpellingWord(s).
Initially I bunged it all in a single presenter with its associated view, and
it was a bit messy, and Erik guided me down a route (that CP nicely supports) -
that my SpellingTest view should have the name/date of the test as well as an
add word input field, but the list of current Words (which I had bunged into a
table) - were actually more elegant as sub-components - hence a WordView -
which renders a single word in a DIV, and for the edit screen I was creating, a
Delete button next to the word (so you could delete it). So a 1 to many
relationship essentials.
This is where the announcements kick in (and lead to my ultimate question).
When you click the Delete button, if I use a sub component - my view will
generate a DeleteWordAnnouncement - which gets fed to my SpellingWordPresenter
- however words in this sense don’t naturally know their parent (the
SpellingTest) - and its the parent test that has a #deleteWord: method.
I’ve been taking with Erik, on different ways to elegantly handle this.
a) you could change the model so words know their parent (in my case, I’m using
a 3rd party model for Flashcards, and they just don’t know this - and adapting
them would be a nuisance
b) my TestPresenter could listen to announcements on the WordPresenter - and I
could get some communications between presenters (although normally the
Presenters just get events from Views, and pure domain models - so it feels a
bit abnormal to consider another Presenter as a sort of model - but I could
live with this
c) given the composable nature of views/presenters (and CP is base on a
WebComponent model) - you could bubble up Announcements, so that if an event
isn’t handled by a view’s immediate presenter, you could re-route it to the
parent of the View (the component owner) and see if it’s presenter could do
something.
I think (c) has a certain expectation to it - in fact when I converted my
initial one-presenter attempt into components, I still had listener code in my
TestPresenter that was expecting to get a deleteWord announcement and I was
initially surprised that I wasn’t getting it (as it was now just going to the
Word component I had refactored out).
So I wonder if others here would expect things to work this way too (and are
there other examples in the wild that lead you here - or scare you away from
this?).
Back to my Announcement question - if C is a good idea - why doesn’t the
Announcer class let you check if if will handle a particular announcement? The
API has #hasSubscriber: and #hasSubscriberClass: , but its missing:
hasSubscriptionsHandling: anAnnouncement
"Answer true if I have any subcribers to anAnnouncement"
^(registry subscriptionsHandling: anAnnouncement ) notEmpty
And I am wondering if this is because it's a bad thing to expect to be able to
check? In my case above, I would want to do this to know if CP should instead
try announcing a message to a parent presenter because the current presenter
won’t handle it. In my example above, my WordComponentView will broadcast that
the delete button was clicked, but its actually a parent view which would
reasonably want to listen to this kind of event and process the delete. And in
a many words scenario (the Test has many words), its unrealistic for the parent
to register to listen to each word component individually (in fact CP sort of
hides this from you), however if you could listen to an event in your TestView,
it seems to come out quite nicely - and looks a bit like this:
viewCreated
super viewCreated.
self view
when: CpNavigationAnnouncement
do: [ :action | self model goto: action location ];
when: CpAddWordAnnouncement do: [ :action | self addWord:
action data ];
when: CpDeleteWordAnnouncement do: [ :action | self deleteWord:
action data ]. <— this is the one I’m talking about
So I’m curious on the overall thought process here, but in particular whether I
should even submit a PR on Announcer for #hasSubscriptionsHandling: ?
Tim
