[Cuis] PluggableListMorph

KenD Ken.Dickey at Whidbey.com
Thu Oct 22 17:39:04 CDT 2015


On Tue, 20 Oct 2015 16:43:02 -0400
"Dan Norton" <dnorton at mindspring.com> wrote:

> PluggableListMorph has valuable behavior but applying it in morphs with multiple lists can be 
> daunting because of the use of the dependency mechanism. AFAICT the tools do not display 
> dependencies and even if they did, it's not clear why some of them exist.
> 
> What is needed is a "PluggableListMorph Principles of Operation" doc, or something similar 
> that can be in the Terse Guide. It should show an example of selection in one list causing the 
> population of another list and selection in that list causing the population of some other 
> morph. Isn't that like FileList? Yes, but we need the whys and wherefors. For example, a 
> method sends #changed: with a parameter referring to another method - why? The design 
> needs to be explained.

Dan,

+1

A tool to detect/show such "out of band" control/change linkages/dependencies would be most welcomed, as would a Principles of Operation.

Taking a quick look at my own code ("guilty as charged, sir")

>> grep "changed:" */*.st
Cuis-Smalltalk-BabySteps/PropertyEditor.pck.st:changed: myMorph
Cuis-Smalltalk-Ropes/Ropes.pck.st:	self changed: #actualContents! !
Cuis-Smalltalk-Ropes/Ropes.pck.st:	self changed: #refetched.
Cuis-Smalltalk-Unicode/UniCodes.pck.st:	self changed: #actualContents! !
Cuis-Smalltalk-Unicode/UniCodes.pck.st:	self changed: #refetched.

I see two cases where one wants to be notified of changes without adding specific code to individual morph instances.  In each case one wants to propagate updates to dependent views.

[1] Change in internal Morph state should update viewers onto that state.
[2] The special case of selection change in a list (PlugableListMorph) should update dependent viewers.

So the simple explanation for "WHY change notification" is to update (perhaps multiple) viewers without doing special notification code in the Morphs being viewed.  The target Morph should not have to know how many, if any, views onto its state exist.

HOW is the registration process:
   Class ActiveModel and its subclass: SystemChangeNotifier

I am a rare user of the change notification mechanism and would also benefit from good documentation and better tool(s) in this area.

Cheers,
KenD <Ken.Dickey at Whidbey.com>




More information about the Cuis mailing list