Re: Models...

From: Magnus Lie Hetland <[email protected]>
> 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.

But models are eminently not values, they are holders. My point is exactly that
comp.prop = should change the value of prop, which could possibly or not be
hold by a model.
If I get a component and want to change a boolean property without throwing
away a model that the surrounding context could have placed in there, I should
always write

comp.modify(prop=1)

comp.prop=1 would discard the model. I think the question is what's the typical
operation: changing the value of a prop, or playing with whether there's a
model there.

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

Of course it becomes only necessary with the value-change semantics for
comp.prop= otherwise we don't need 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...)

it also depends on whether Dallas's approach grabs setters/getters or not.

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

my point was the model to value-type conversion, beyond that the conversions
are up to wrappers.

>
> > Unrelated:
> > *) We should check the issue with setX etc and setGeometry and wrapper
> > subclasses overriding only setGeometry
>
> Which issue was this, again?

that in some backends e.g. the generic CompWrapper defines all setX,setY etc
and setGeometry but then some subclass (e.g. WindowWrapper) redefine only
setGeometry or getGeometry and does computations on the values, but if one
changes only x for example, the inherited setX is called and this does not do
the right thing. I think all this (interaction between setters flavors) is
undertested.

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

but I can still set comp.geometry and retrieve it, and the splitting is done
(it seems to me) at wrapper level, so I'm not sure what happens if I put a
model in comp.x and modify comp.geometry ???





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