Re: [Pharo-users] Spec "bindings"

[Stephane Ducasse]

Hi rob

we are discussing in Peter and reading your solution.
Now about your example, I think that the

Presenter >> subject: aDomainObject
 subjectHolder := aDomainObject asValueHolder

We should not have countHolder in the domain object. In the domain object
we should only have the domain and no value holder. Now to access a
part of a domain
object to refresh/change it without changing the whole, we should
have something similar to AspectAdaptor in VW.

What do you think?

Stef


On Sat, Sep 30, 2017 at 9:21 PM, Stephane Ducasse
 wrote:
> 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
>  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  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
>>>

Re: [Pharo-users] Spec "bindings"

[Stephane Ducasse]

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
 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  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

Re: [Pharo-users] Spec "bindings"

[Stephane Ducasse]

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  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
>

Re: [Pharo-users] Spec "bindings"

[Stephane Ducasse]

Good luck because this is heavy after a while. I'm finishing a first
full version of the book for the prague lecture as well as all the
slides (done) now working on exercises tedious because also a long
term effort.

On Sat, Sep 9, 2017 at 10:51 PM, Rob Rothwell  wrote:
>
>
> On Sat, Sep 9, 2017 at 5:06 AM, Stephane Ducasse 
> wrote:
>>
>> 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
>>
>>
>
> Hi Stef,
>
> Thank you very much for the encouragement,  and good luck with all your
> endeavors.  I have a huge MOOC project going on at work myself (you know how
> that can be), but I will keep experimenting with this and try to be prepared
> when there is some time available!
>
> Take care,
>
> Rob

Re: [Pharo-users] Spec "bindings"

[Rob Rothwell]

On Sat, Sep 9, 2017 at 5:06 AM, Stephane Ducasse 
wrote:

> 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
>
>
>
Hi Stef,

Thank you very much for the encouragement,  and good luck with all your
endeavors.  I have a huge MOOC project going on at work myself (you know
how that can be), but I will keep experimenting with this and try to be
prepared when there is some time available!

Take care,

Rob

Re: [Pharo-users] Spec "bindings"

[Rob Rothwell]

On Sat, Sep 9, 2017 at 7:11 AM, Peter Uhnak  wrote:

> Hi Rob,
>
> I'm making a note to look at your proposals and I will discuss it with
> Stef later.
>

Thanks, Peter, I appreciate any insights you can offer.  I will continue
experimenting, and just wanted to make sure I figured out how to share my
ideas during a window of opportunity I had.


> >
> > he has more and younger braincells than me
>
> But not enough connections between them. The cells just sit there alone
> and are not talking to anyone. :(
>

I can certainly relate to that! Unfortunately, some of my best thinking is
out loud trying to explain something I don't really understand to someone
else...

Take care,

Rob


>
> Peter
>
>

Re: [Pharo-users] Spec "bindings"

[Peter Uhnak]

Hi Rob,

I'm making a note to look at your proposals and I will discuss it with Stef 
later.

> 
> he has more and younger braincells than me

But not enough connections between them. The cells just sit there alone and are 
not talking to anyone. :(

Peter

Re: [Pharo-users] Spec "bindings"

[Stephane Ducasse]

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  wrote:
>
>
> On Fri, Sep 8, 2017 at 1:24 AM, Stephane Ducasse 
> 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 

Re: [Pharo-users] Spec "bindings"

[Rob Rothwell]

On Fri, Sep 8, 2017 at 1:24 AM, Stephane Ducasse 
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 

Re: [Pharo-users] Spec "bindings"

[Stephane Ducasse]

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
>> > 
>> > 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 
>> >> 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 

Re: [Pharo-users] Spec "bindings"

[Rob Rothwell]

On Thu, Sep 7, 2017 at 2:12 AM, Stephane Ducasse 
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;
>

Re: [Pharo-users] Spec "bindings"

[Stephane Ducasse]

> 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 
> 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 
>> 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" 

Re: [Pharo-users] Spec "bindings"

[Rob Rothwell]

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


That would allow you to initialize the domain model of each component
relative to your overall model.

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."

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.

Take care,

Rob

On Tue, Sep 5, 2017 at 6:08 PM, Stephane Ducasse 
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 
> 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
> >
>
>

Re: [Pharo-users] Spec "bindings"

[Stephane Ducasse]

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  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
>

[Pharo-users] Spec "bindings"

[Rob Rothwell]

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