Hi Rob I discussed with peter and I hope that he has more and younger braincells than me. I'm *****super***** busy with lectures preparation, workshop preparation and business issues. So I would love to get some time to get concentrated but not before beginning of October at the minimum. May be when I am at Prague we can discuss with Peter.
Stef On Sat, Sep 9, 2017 at 4:43 AM, Rob Rothwell <r.j.rothw...@gmail.com> wrote: > > > On Fri, Sep 8, 2017 at 1:24 AM, Stephane Ducasse <stepharo.s...@gmail.com> > wrote: >> >> I like the idea about your extension. >> We should really get it so that we understand it. > > > I published some experiments on smalltalkhub in a project called > "Spec-Bindings" (owner RobRothwell) that loads into a clean 6.1-64 image. > > It just has some LabelModel and TextModel capabilities with a few tests and > very simple examples. I've never really used smalltalkhub before, though, > so please let me know if I didn't get it set up right. > > I changed and added methods only at this time, but there ComposableModel > probably needs an instance variable for the subject/domain model. I didn't > want to start a new branch of Spec-Core, though, so I created a Presenter > subclass to create new UIs with, but the widgets all have a ValueHolder > already (with different names per widget). > >> >> >> >> > 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. > > > Hopefully my examples show that it shouldn't be too hard to modify this. > >> >> >> >> > >> > 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) > > > Like you said, it just needs some continuous improvement! > >> >> >> > >> > >> > 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. > > > I'll try to recreate my VW experiments, which needed a sort of "complex > object value holder" so you could have something like a Person object in > your list that that displayed some representative string like a full name. > Then, if any of the components of Person (or any of their their > sub-components, like aPerson personName firstName) changed, these changes > propagated to the to top and let the list know that one of it's items had > changed so it knew to update it in the list. > > Take care, > > Rob > >> >> > >> >> >> >> >> >> 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 >> >> >> > >> >> >> >> >> > >> >> >> > >> >
