Re: I'm still here...

> "Samuele Pedroni" <[email protected]> wrote:
>
> >This makes sense, although things get complicated if we want (as Magnus
> >suggested in order to simplify wrappers) to have setters that are called or
not
> >depending on whether wrappers.widget is set.
>
> Couldn't this be handled in the wrapper itself? For example:
>
> widget.text = "blah" -->> setText(self, val): if self.widget: ...

that's how it is handled now,

>
> Or are we absolutely trying to avoid this?

you should ask Magnus.

> What do you think?

the wrapper interface was defined in terms of push and pull, setters and
getters being an internal implementation detail of the wrappers, e.g. in the
push/pull logic in wrapper there's code to deal with aggregates (like geometry)
(*) and using the setters and getters bypasses that.

Your delegation scheme expects a wrapper to have push/pull/setters/getters
which means you  are redefining the proxy/wrapper interface. This simplifies
dealing with models but it also changes the rules, so I'm asking

- for what should be models supported? text, listbox data or also x,y or what
not?
- should models be able to interact with aggregates or not, if yes how?

the questions' point is to address whether expecting getter/setter to be there
for a property for which a model is installed is meaningful in general.

For implementation: ignoring the aggregates' issue the possibilities are:

1) [your proposal] when installing a model for a property, both a setter and
(optionally) a getter are passed along,  then then push/pull mechanism is not
used for such property as long as the model is in place.
2) [other] when installing a model for a property both the proxy and the
property name are passed along, setting the value in the model would trigger
proxy.push(prop) and asking the value of the model should  ask the proxy to
pull the value from the widget. But then we need also a mechanism to change the
value of a model avoing the proxy.push(prop) call for a specified proxy, to use
when the proxy is changing the value.

both approaches can be made work, but 1) is simpler up to the above
caveat/questions but also 2 does not solve the questions directly.

As a side note: interestingly there should a way to distinguish models that can
be installed for a property that can be changed also through the UI (e.g. a
textarea text) and so need a getter and can be installed only in one component,
and models that can be changed only programmatically and so do not need a
getter and can be installed in more than just one component.

(*) I'm not sure all backends use that mechanism properly: some backend define
a general CompWrapper with e.g. both setX and setGeometry but then some
subclasses redefine only setGeometry, but comp.x would call the inherited setX
that may or may not do the right thing ???




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