Re: Models...

Dallas Johnston <[email protected]>:
>
> In my implementation, this is correct both for when value is a
> number and for when value is a model. I believe this is exactly what
> you want. 

Yup. Though I wouldn't bet on this behaviour for numbers (since you
can't assume identity between equal numbers, and you can't be sure
that the back-end will give you the same number back, even though it's
equal -- the same goes for strings :)

> >>>> proxy.width = model = NumberModel()
> >>>> # User modifies proxy graphically
> >>>> proxy.pull('width') # proxy.width is modified in-place
> >>>> # model will now trigger an update in its views
> 
> Ok... what I did was a bit different. This is exactly what happens
> now in the code that I banged out today, save the model installation
> bit. In my code, it is: proxy.installWidthModel(NumberModel()),
> where the function 'installWidthModel' is created on the fly using
> nested scope. The same goes for remove<Property>Model. 

Hm... This is the same Samuele talked about (more or less). Why is
this needed (as opposed to the existing mechanism)?

> >But what about proxy.push()? Samuele brought this up: We might end up
> >with Models in the Wrapper's setters. 
> 
> proxy.push() should update the model based on the value obtained
> from the the push.

You mean proxy.pull() here? (You don't obtain any values from push,
after all.)

> unfortunately, I'm not sure that proxy is even
> capable of handling a push from the wrapper now for any value in
> state, unless the wrapper has touched proxy.state itself, in which
> case the model would be properly updated. But this -having wrapper
> touch proxy's state directly- cannot be the desired functionality,
> is it?

No... I guess an alternative is to let Wrapper.pull return a
dictionary, rather than modifying a given dictionary. This sounds
reasonable to me... E.g:

  proxy.pull('foo', 'bar') -> d = wrapper.pull('foo', 'bar')

  d == {'foo': 123, 'bar', 456}

  proxy.rawModify(**d)

Here proxy is taking care of the modification -- it just gets the
correct values from the wrapper through wrapper.pull(*names), which
returns a dictionary with the correct values.

As far as I can see, this should fix the problem.

> And this checking seems to be broken now!! It has been broken since
> it first appeared there.. I had to hack up qtgui with 'if
> self.widget:' statements just to get anygui running again, even
> before I started touching Model oriented stuff...

Yeah -- I think this requirement was introduced when Samuele entered
the DummyWidget -> None translation. So, yes, currently you do need to
check whether self.widget is None (I don't think a plain Boolean check
is good style here...) -- but that's one of the issues we're
discussing: Whether or not to add this check in Wrapper itself.

> >The more I think about it, the more I'm convinced that this is the way
> >to do it.

I was here referring to placing the int(x) in Wrapper rather than
Proxy, so that keeping a Model (or anything else) in Proxy.state is
OK, and the Wrapper will convert things as needed.

> Well, as it now stands, the code I finished tonight seems to do just
> what you want =). It keeps Wrapper from having to mess with Models,
> and it keeps Attribs very clean.

Good.

> Should I check it in???

Sure.

I'm not quite convinced about the model registering methods (yet ;)
though... I still like the original version of the mechanism, which I
think will work just as well.

(BTW: Weren't you supposed to go to bed? ;)

-- 
Magnus Lie Hetland        Practical Python          The Anygui Project
http://hetland.org        http://ppython.com        http://anygui.org


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf