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