I must say it was an off color moment to state it this way. Rather I should say, morphs must be intelligent to update: themselves, but models can choose to have the #changed: call when they get to have a need to connect more than one view. So i should rewrite the examples as

...

changeModelSelection: anInteger

setIndexSelector ifNotNil: [model perform: setIndexSelector with: anInteger]. "update this morph implicitly without needing model #changed: call" self update: getIndexSelector

Similar for the acceptInTextModel, in an MVP world, view or widget has to be intelligent for it's own updates, not wait only on the model or controller to send updates...even for such obvious update On Feb 6, 2012, at 8:46 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:

It has been done like that because sometimes ( and in fact quite often for complex UIs ), the model want to perform some actions before the UI is updated. But I am agree that for some instructions, like selection changes, it could (should ?) be send directly by the morph.

Ben

On Feb 6, 2012, at 5:49 AM, S Krish wrote:

...

I am checking out on the basics of the PluggableTextMorph and PluggableListMorph .. and its cousins.

PluggableListMorph >> changeModelSelection: anInteger

setIndexSelector ifNotNil: [model perform: setIndexSelector with: anInteger].

here it is the responsibility of the model to send #changed: getIndexSelector. why..?

why not a simpler generic:

changeModelSelection: anInteger

setIndexSelector ifNotNil: [model perform: setIndexSelector with: anInteger]. "sends the call to all dependents of the model implicitly" model perform: #changed: with: getIndexSelector

thereof the models anywhere need not bother sending #changed: calls... !

similarly:

acceptTextInModel

..... [^setTextSelector isNil or: [setTextSelector numArgs = 2 ifTrue: [model perform: setTextSelector with: acceptedText with: self] ifFalse: [model perform: setTextSelector with: acceptedText]] ] ensure: [unstyledAcceptText := nil]. model perform: #changed with: getTextSelector

We can avoid these in the methods if implemented across all Pluggable??Morphs

Workspace class>> openContents: aString

^ self new open; contents: aString; "funny is this itself calls #changed:" "changed: #contents;" yourself

Makes common sense to me.. rather than expecting the model to explicity call #changed:..this "view" / widget knows its model and it implicitly invoking #changed: is cleaner abstraction, unless a use case exists which may break infrastructure/ whole base doing this..

This way all models associated with various Pluggable??Morphs will work perfectly fine on just a setter call without extra line being added everywhere in the application code, apps need to bother about changes to other symbol viz: updating a list selection index causes another widget to refresh its content..