> Hi Stef, > > I think you are correct and you would still always perform actions like: > > initializeWidgets (to create components and sub-components) > initializePresenter (to define interactions between components) > > > But, there could also be a third initialization step like > > initializeSubject: aSubjectModel
Yes I do not remember exactlty but I have the impression that I identified the same problem recently because I wanted to do MyApp on: aModel and I realized that the flow proposed did not let me do it that way (may be I'm incorrect). > That would allow you to initialize the domain model of each component > relative to your overall model. Yes. > Then, by exposing the aspects of your model available for viewing by a UI as > ValueHolders, it looks pretty straightforward (for simple objects) to extend > Spec to use those ValueHolders so that UI elements can implicitly update > themselves. > > The source of my inspiration is the Dolphin "Better Hello World" example(s) > here: > > http://object-arts.com/blog/files/better-hello-world.html > > > To try it out, I added a few Spec extensions and tried a little "counter" > test (like your MOOC example) displayed by a CounterApp (having an increment > button, decrement button, and label to show the count) such that > > CounterApp showOn: counter > > triggers > > CounterApp>>initializeSubject: aSubjectModel > > subject := aSubjectModel. > > countLabel initializeSubject: subject countHolder > > This results in replacing the UI label ValueHolder with the Counter's > "count" ValueHolder. If I had more aspects of my model I wanted to connect, > I would do it here, or if I wanted to connect the same thing to multiple > widgets (like a slider, for example), I would do that here as well. > > This allows direct interactions with the Counter model (for example, an > "increment" button) to be reflected directly by the UI without having to > explicitly update the value after the interaction or listening for events. > > I'll have to think about it some more, but I think Spec has what it needs > already to create a nice set of "type presenters" instead of what is > currently seems more like "widget presenters." Indeed. Thanks a lot for your analysis. > Then, instead of adding a LabelModel to a ComposableModel, you could add > something like a NumberPresenter and specify the spec you want to use (which > would in turn display the desired widget). > I didn't go that far yet, and created a NumberLabelModel for my example > above. It worked, but seems like the wrong way to go about it. Or maybe you > need both...I'm not sure! > > I also want to take a look at self-updating complex widgets as well (lists, > tables, etc...) so that telling a list presenter it's list means that adding > a value to that list could automatically update the widget and so on. > I had some crude prototyping success with that in VW before deciding > (hopefully for the last time) that "native" widgets aren't as important to > me as a solid and simple way to connect a model to a UI presentation. > This seems much easier to achieve in Pharo, and after years of intermittent > attempts I am hopeful that my knowledge level has finally become sufficient > to contribute something to this heroic effort. Superb. We are discussing with peter (but EsUG is so intense and I should finish the lectures for real now that I do not have the braincells) about a pragma driven to declare menus because this is a real lack. What I suggest is - Please please continue your experiment. - It would be great if we can compare some typical examples. - After that we can take a decision and improve/modify Spec and update the documentation. I want to write a small interface for a small app. I checked my code and I thought that it was strange that we cannot initialize presenter once the model is done GameListModel new on: GameCollector smallCollection; openWithSpec "protocol: #initialization" initializeWidgets listModel := self newList. listModel items: (collector collectionNamed: #owned) and then back then I realized that I was wrong. Stef thanks for this discussion. > > Take care, > > Rob > > On Tue, Sep 5, 2017 at 6:08 PM, Stephane Ducasse <stepharo.s...@gmail.com> > wrote: >> >> Rob >> >> Spec deserves another pass. >> I see your point with showOn: now I do not see how you could avoid the >> presenter building. But may be I'm not enough into it. >> So I'm interested in your feedback. >> >> Stef >> >> 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 >> > >> >
