Re: Q: wrappers push/pull and models

From: Magnus Lie Hetland <[email protected]>


> Samuele Pedroni <[email protected]>:
> >
> > Hi.
> >
> > Are models already supported by current design vs. implementation?
> >
> > Checking the pull/push counts I noticed that e.g.
> >
> > comp.visible = 1
> >
> > (if the widget is there) will first pull visible and then push the
> > new value.
> >
> > The pull visible logic seems there to deal with models
> > (Attrib.rawSet). It seems (me skimming the code) that models will be
> > pushed down to wrappers and be expected to be returned form wrappers
> > by pull.
>
> Hm... Tricky.
>
> > Are really wrappers expected to be able to deal with models
> > vs. plain values?
>
> Not really; for setters, it would be nice if this worked -- the models
> should be polymorphically equivalent to the primitives (and the
> wrapper should take care of conversions)

Yes, but given that we cannot expect wrapper code to preserve models (expecting
that would mean that they too must
store the models somehow, because native widget cannot typically supply storage
for them ) maybe the conversion could be dealt at proxy/push/pull level.

> and pull should use in-place
> modification anyway,

that's the part that I'm not sure (but I just skimmed stuff) wheter is already
correctly implemented.

> so it doesn't matter if the value returned from
> the wrapper is a primitive value rather than a model.
>
> I think it should be possible to make this work... :]

Yes, the problem is more that it is pointless to optimize push/pull/Attrib
logic until this is worked out, because optimization
that are OK for plain values may be not for the models logic, OTOH I did not
expected setattr to pull from wrappers, because in the case of plain values it
is not needed to know the old value, and in the case of models the model should
be preserved at the proxy level, because it cannot be expected to preserved at
wrapper level (explained above).

> > Or should models be dealt and live only at the proxy level, with
> > push and pull with/from wrappers only dealing with values and eager
> > changes being managed through events?
>
> Eager changes should be managed only through events, yes.

>  The model
> behaviour is *not* dealt with by the wrappers. The wrappers should
> *not* modify the objects they are passed from the proxy.

indeed but not messing with vs. keeping them alive through storing are
different things. It seems (but maybe I'm wrong) that the current code needs
the latter, which would be complexity "pushed" down in the wrappers again.

On a related note: is that correct that with the current design

comp.boolprop = BoolModel(1)
comp.boolprop = 0

the second line should discard the model and substitute it with a plain value?

[[ Just musing, an alternative design could be:

comp.propModel =fooModel() # install model
comp.prop =  ... # change value inside model and wrt widget
comp.prop  # return value/model (e.g. depending on model being a container or
singled value)
comp.propModel = None [or del comp.propModel]  # deinstall model ]]

regards.



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