>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 > >
