Re: Models...

Samuele Pedroni <[email protected]>:
>
> 
> From: Magnus Lie Hetland <[email protected]>
> > >>> proxy.attr = value
> > >>> proxy.attr is value
> > 1
> >
> 
> OTOH personally I still find to require the idiom
> 
> proxy.modify(attr=newval)
> 
> to change the value/a model in-place without substituting it awkward.
> 
> IMO
> 
> proxy.attr = value should change a possible model in-place
> OTOH proxy.attr should return the model or the value

Hm... The original ideas for the MVC stuff were meant to avoid this
sort of special-casing in the code -- i.e. an attribute is bound to a
value, and that's that.

> and then a model would be installed with
> 
> proxy.installModel('attr',Model())

I'm not immediately enthusiastic about this. It's an interesting idea,
though -- maybe I just need time to adjust to it :]

[snip]
> the shorter and sweeter to write we can make the wrappers the better,

Yes -- I was only talking about the conversion (i.e. requiring the
wrapper to call int(x)) -- I don't really like the "self.wrapper is
not None" checks. I think they should be put in push/pull.

> OTOH they should be copy-and-past-proof, and not too much things should
> happen implicitly, so:
> 
> [assuming that Dallas saying Proxy manage models means that he has not adopted
> passing settesr/getters along to models (?) ]
> 
> - having getters to assume that widget is set is OK, if this can be enforced,
> because it makes sense in general and does not require special cases

Good. Perhaps an assert in pull to enforce this?

> - for setters to check explicitly for widget is sensible, because some need a
> widget already there and some trigger widget creation so doing otherwise would
> require some magic/implicitness

Well... It's just a matter of adding "if self.wrapper is not None" to
Wrapper.push -- no? Quite a simple thing, it seems to me. (Or... Hm.
Won't work with setContainer. Darn...)

> OTOH apart from implemetation issues at the higher levels, I don't see why it
> is bad to assume/enforce that only values are passed to wrappers.

Well, how would you do it? If I pass you an object, how do you convert
it to a primitive value? How do you know whether to convert it to
(e.g.) a string or an int? Both may be possible...

> I mean
> expecting them to convert things is also sensible but makes wrapper code more
> convoluted and does it increase clarity?

Well... My thought was that the needs of various back-ends may be
different here. For instance, some back-ends may accept floating-point
coordinates, while others need ints... Etc., etc. I just think this
sort of conversion shouldn't be done by the front-end.

> Unrelated:
> *) We should check the issue with setX etc and setGeometry and wrapper
> subclasses overriding only setGeometry

Which issue was this, again?

> *) What is the general opinion about aggregates and models behavior?

There are no (front-end) aggregates anymore (we killed them to get rid
of the rules engine etc.) -- only aliases. So if you do

  proxy.geometry = rect = RectModel()

the proxy will not keep any references to rect -- it will split it
apart and assign the components to the atomic attributes.

The aggregates in the back-end have nothing to do with models.

IOW: You can't have an aggregate model.

> Samuele.

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