Hi peter :)
If I recall, one of the key problem is that the state of certain widgets
does not let the adpater do its job nicely and disappear
after the bridging.
Stef
Le 9/2/16 16:31, Peter Uhnák a écrit :
The widget becomes available only once the UI is built, however when
you are configuring Spec it is not yet built so it's not available and
thus the ugly nil check (well, one of the reasons anyway).
This is a big problem with morphic/spec ui elements. You never
know for sure
what code this
self update ---> search through all (dynamicly added)
dependents and notify
will finally call.
I don't think there is any way around it. You have to decouple
view(s) from model(s), and, hence have those propagation
constraints by way of notifications.
About a year ago we were discussing this with Stef and one of the
options was to expose all value holders (which has happened in the
meantime) and have adapter just connect Spec with Morphic.
This is a bit older and needs updating, but I think it still holds
somewhat https://gist.github.com/peteruhnak/0fc752d0cea9bde69315 (the
idea was to to connect Morphic directly to observe Spec and therefore
not have Adapter at all during runtime).
Peter
On Tue, Feb 9, 2016 at 1:46 PM, stepharo <steph...@free.fr
<mailto:steph...@free.fr>> wrote:
Hi nicolai
I agree. I will have a look at the Calipso experience of Alain.
Because may be Calipso + Spec layout format would be much nicer.
Did you look at it?
Alain just brainstormed but this is interesting for thinking.
Stef
What I hate also is that the
AbstractApdate>>update: aSymbol
self changed: aSymbol
This is a bit terrible because the adpater should not exist at
runtime
and adapter should just encapsulate how to create and set the
communication
between the model and the view. Now it is in the middle and this
is not good.
stef
Le 8/2/16 11:31, Nicolai Hess a écrit :
2016-02-08 10:37 GMT+01:00 stepharo <steph...@free.fr
<mailto:steph...@free.fr>>:
Hi guys
I should say that I'm sick (gift from my little boy) so may
be this is obvious.
I'm looking at the code of Spec and I hate this code :)
widgetDo: aBlock
^ self widget ifNotNil: aBlock
I do not see why widgetDo: has to test for nil
So I transformed
widgetDo: aBlock
^ self widget ifNotNil: aBlock
into
widgetDo: aBlock
^ aBlock cull: self widget
BTW I hate all the cull: call. They are connected with
sloppiness). It is far too easy to use cull:
I do not know how many arguments, I do not care I use cull:
cull: is slow slow and help producing messing API.
And it broke. The methodBrowser example did not work anymore
and many others.
Debugger felt down....
I feel sad. Now my brain is dead so I cannot concentrate more.
Stef
This is a big problem with morphic/spec ui elements. You never
know for sure
what code this
self update ---> search through all (dynamicly added) dependents
and notify
will finally call.
In this example we are about to *built* the widgets and in this
run , we change a component that
will update all dependents goes back and forth between model,
adapter and widget. And all
before the widget is actually accessible for the widgetDo: call.
(and, REALLY we need to clean this up. This is really bad code if
we announce a textChanged announcement for
a text component, if we *initialize* an *empty textcomponent*
with an *empty text*!).
