I like the idea about your extension. We should really get it so that we understand it.
>> > countLabel initializeSubject: subject countHolder >> > > > 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. Yes excellent. > >> >> 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. yes this is not really good. > > 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. To fit Spec (but Spec is certainly too limited) > > > 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. mistake :) Lack of analysis. We are learning while doing it so let us continue. > >> >> >> 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 >> >> > >> >> >> > >> >
