On Thu, Sep 7, 2017 at 2:12 AM, Stephane Ducasse <stepharo.s...@gmail.com> wrote:
> > 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. > You're welcome. Thank you very much for your time--it's helpful to know there probably isn't some sophisticated wizardly way to do this that I am not even able to see or comprehend! > > > 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. > Good luck! > > > 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. > That's a really good idea since I am no Spec expert! I can probably make a few things work the way I'd like them to, though, in order to produce some typical examples like master-detail lists and so on. > 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 > Right...you can see in Spec that each type of widget creates a static ValueHolder ( such as '' asValueHolder ) for each type of widget and does not currently offer a method to swap it out with a new one. Also, there are probably more available Morphic widgets that could be adapted (like a progress bar as an number presenter, for example). > > 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. > It would be interesting to hear the arguments against lists and trees updating themselves when their underlying objects change. It looks like Spec, VW, and Pharo all require you to monitor and replace the UI list when something is updated. > > Stef > > thanks for this discussion. > You're very welcome. Take care, Rob > > > > > 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 > >> > > >> > > > >
