Hi rob I wrote this missing chapter and I think that it exhibits the changes you wanted to introduce. So let me know.
Stef On Sat, Sep 30, 2017 at 9:13 AM, Stephane Ducasse <stepharo.s...@gmail.com> wrote: > Hi rob > > where can I find your code because I'm really thinking that something > is missing in Spec. > I'm writing a little editor for a gameItem and I should go through and > I would like to use it > as an example of what I do not like. > In fact I would like to have all the models to work on aspect of the > domain model. > May be this is avaialbale in spec but I forgot and I forgot to > document it in the book. > > Stef > > > On Tue, Sep 5, 2017 at 8:49 PM, Rob Rothwell <r.j.rothw...@gmail.com> wrote: >> Hello, >> >> I was wondering what more experienced users than myself thought of the idea >> of an explicit Spec "connection point" to a domain model object similar to >> Dolphin's "showOn:" method, like: >> >> CounterApp showOn: counter. >> >> This would perhaps trigger something like Dolphin's Presenter>>model: >> message (although I've always found the use of "model" confusing when there >> are so many "models" involved.) after the widgets had been created: >> >> ComposableModel>>initializeBindings: anObject >> >> In many cases, if your domain model uses ValueHolders as well (like Spec >> does), making a connection could just mean replacing the Spec ValueHolder >> with your domain ValueHolder so changes to the domain model would >> automatically propagate to the UI presentation without providing explicit >> code in ComposableModel>>initializePresenter. >> >> However, since I am still trying to understand and learn Spec, it's quite >> possible I am missing some key point and there are reasons not to explore >> this line of thinking! >> >> Thank you, >> >> Rob >>
Patterns.pdf
Description: Adobe PDF document
