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 <[email protected]> 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.. >> >> >> >> >
