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.. 
> 
> 
> 
> 

Reply via email to