Exceptions are real, so your use case might justify it. In my experience I never had to test whether an announcer has some subscription, and before using announcements whether an object has some "listener" to some event.
I always saw announcements as a fire and forget kind of architecture. Not sure if I'm answering your question (probably not), but let's start this conversation :-) Esteban A. Maringolo On Tue, Apr 27, 2021 at 11:04 AM Tim Mackinnon <tim@testit.works> wrote: > From my rather long ramble below - I am still curious if its distasteful > to have a method on Announcer > > hasSubscriptionsHandling: anAnnouncement > "Answer true if I have any subscribers to anAnnouncement" > > ^(registry subscriptionsHandling: anAnnouncement ) notEmpty > > Tim > > On Thu, 22 Apr 2021, at 11:34 PM, Tim Mackinnon wrote: > > 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 > > > > >
