I get dizzy (may be time to go to sleep) but I wonder
why do we need to check first the the window changed and after that it got closed?
Especially since whenWindowChanged: presuppose that we have access to window.
Am I missing something?
self whenWindowChanged: [ :w |
w whenClosedDo: [ self clear ] ].
ComposableModel>>whenWindowChanged: aBlock
window whenChangedDo: aBlock
WindowModel>>whenClosedDo: aBlock
isClosedHolder whenChangedDo: [:value |
value ifTrue: [ aBlock value ] ]
IMHO, APIs that, in essence, glue together announcers and non-self subscribers, are bad, it's an extra level of indirection with little gains. (And quite a few restrictions)
Let the announcers be resolvable, and leave it to subscribers to do the actual subscribing.
To me, it looks like ValueHolders are being used for the sake of using ValueHolders, rather than delivering events in the simplest way possible...
Say you do something like
WindowModel >> announcer
windowAnnouncer := Announcer new
WindowModel >> createWindow
window := blahblah.
window announcer when: GenericWindowEvent do: [:event self announcer announce: event ]-
And all the modelling widgets are free to respond to any window events by subscribing to the models windowAnnouncer, rather than registering blocks for value holders linked to single type changes.
users of whenClosedDo: would instead do something like (usually in an initialize method where it's passed as a windowModel parameter)
windowModel announcer when: WindowClosed do: aBlock
and as such, the code that starts with self whenWindowChanged (I assume in the initialize method on a ComposableModel subclass?)
window announcer when: WindowClosed do: [self clear]
Cheers,
Henry
1004