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