I appreciate the further thoughts of others - I should go back and look at Dolphin code (I think there are ways to run it on Mac now?).
The upcasting Richard refers to is what I'm trying to do - which is how I got interested in understanding if you could tell if someone was subscribed to an event, as if not - then you could pass it up to the parent to - re-announce it via the announcer of that parent (in CP - the announcers are by presenter, so hence the handoff). In theory it's quite neat - but I did see some deprecations in Announcer trying to stop too much knowledge leaking out. However, knowing if an event has any listeners doesn't on the surface seem too controversial - but I can see that everyone approaches this idea with understandable caution. Possibly this is masking some other approach to this - or - I can happily have an extension method on Announcer - or - I can propose this method in a PR for symetry with some of the other #hasXXXX methods. Tim On Tue, 27 Apr 2021, at 5:31 PM, Richard Sargent wrote: > I have seen something called upcasting and downcasting (as contrasted with > broadcasting). Mostly, I have seen it in UI layers. > > e.g. a leaf node receives a change notification, decides it isn't interested > in handling the notification, and so passes it up to its parent, etc. > > Downcasting is similar but in the opposite direction. e.g. a window receives > an event and asks its children to handle it, and they do the same. In this > case especially, the one that handles the event needs to mark it as handled > so that no one else is asked to handle it. > > On April 27, 2021 5:49:56 AM HST, Tim Mackinnon <tim@testit.works> wrote: >> Hi guys - yes that fire and forget was always how I had viewed >> announcements, and potentially my scenario is misusing "announcements" which >> is why I was interested in views here. >> >> However - as announcements are typically a mechanism for farming out >> processing to others - how does one handle the scenario that you might only >> want one object to handle the announcement (and not others)? >> >> in my specific example, with MVP - a view, totally decoupled in a web >> browser, wants to pass on a button click to a presenter - however it not >> clear what the best mechanism to bubble up that handling should be? If the >> immediate presenter of the view can handle it - great - but if not, how >> would you continue to broadcast wider to see if someone higher up the parent >> component chain can handle it? >> >> If you go fire and forget (which is how I had viewed announcements prior to >> this specific case) - then you have the problem a different way - when >> someone processes an announcement it might already have been handled earlier >> and so the consumer either has to check first, or their work is simply >> ignored as the announcement payload could just filter a response out. >> >> In my head, I'm sort of thinking this is akin to CPU interrupt chaining - >> where an interrupt can cascade up a stack if not handled OR like object >> inheritance where an object can choose to override a message and stop it >> from cascading up the inheritance chain. >> >> Maybe announcements aren't intended for this at all - although it seems an >> elegant way to handle it - with just 1 method addition to Announcer (but it >> does slightly expose things - albeit in a structured way - and similar to >> the similar #hasSubscriber:). >> >> I'm sure it "depends" - but interested in other observations from the field, >> as I'm sure I'm not the first person to hit something like this. >> >> Tim >> >> On Tue, 27 Apr 2021, at 3:51 PM, Sven Van Caekenberghe wrote: >>> The whole idea is to decouple producers and consumers, like in >>> messaging systems. >>> >>> You should not care if there are other listening, just like the >>> listeners should not care if there is someone posting data. >>> >>> Asking for subscribers is introducing a coupling. >>> >>> The announcement mechanism will/should deal with this in an efficient way. >>> >>>> On 27 Apr 2021, at 16:03, 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 >>>>>
