Re: Models...

Magnus Lie Hetland <[email protected]> wrote:

>> 'widget.__getattr__' will have returned the value that 'property'
>> represents.
>
>I *absolutely* don't want this sort of behaviour. The following should
>hold (for objects that can be modified in-place):
>
>>>> proxy.attr = value
>>>> proxy.attr is value
>1

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. 

>If value is a model, that shouldn't make a bit of difference. The only
>special-casing of models is handled by the in-place modification
>(which uses the value attribute when available) and the assignee
>protocol. Nothing else should be needed.
>
>... except for one thing... ;)
>
>In proxy.pull(), all attributes should be modified in-place (if
>possible) by the value returned from the wrapper. This ensures that
>models aren't replaced etc. (Not sure if this is correctly implemented
>at the moment -- I seem to recall Samuele pointing out some errors
>there). So, the following should work:
>
>>>> 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. 

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

>But, as I said, I think it is better to require the Wrapper to make
>fewer assumptions about the values it receives; e.g. a coordinate will
>be number-like, but not necessarily an int. If the back-end needs an
>int, then the setter should be implemented something like:
>
>  def setX(self, x):
>      if self.widget is not None:
>          self.widget.x = int(x)
>
>(assuming that we keep the "wrapper is not None"-checking in the
>Wrapper).

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

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

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.

Should I check it in???

>> And I cannot refer to the old version of Attribs.py without mucking
>> about with cvs, so I'll have to look into it tomorrow.
>> 
>> cheers all,
>> --Dallas 
>
>-- 
>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
>

__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/


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