Re: I'm still here...

Dallas Johnston <[email protected]>:
>
> "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: ...
> 
> Or are we absolutely trying to avoid this?

Not absolutely. I just thought it might be nice to put this in
widget.push(), to avoid having the check in every setter in every
back-end...

[snip]
> >Yes, personally, I would prefer  comp.prop and comp.prop=  to deal with
> >values/and values in models, and have a different spelling for
> >installing/deinstalling models,   and not have the modify(prop=...) idiom
> >anymore.

I guess this is the main point of contention (or one of the main
points).

It may well be that you (Samuele and Dallas) are right about this.

But if we do use the model installation approach, I think also
attribute _access_ should retrieve the value (and not the model) --
doesn't that make sense?

IOW, proxy.installFooBarModel(model) would make model.value mirror
proxy.fooBar? Sounds like an OK solution to me.

What do you say? Is this an acceptable version of the scheme?

> Yeah, I don't see anything wrong with making the logical distiction
> here in the code. Assignment is more times than not directly
> associated with properties, whether directly or indirectly, and
> Installation with the concept of adaptaters or proxies (which is
> what i believe Models essentailly are in this case). Maybe it would
> be more precise to say that we need to install a delegate for the
> actual model, but leave the verbiage out of the API. So,
> InstallTextModel would really set up a TextModel delegate inside of
> Attribs that handles all the push-pull semantics, which would allow
> for TextModel itself to focus more on behaving like a Model.

Sounds interesting.

> What do you think?

I think the model installation method sounds good, if it is possible
to have the relevant object properties behave (more or less) like
normal properties, and only have the model mirror that property (i.e.
not have it returned upon property access).

If we decide to go this way, there might not be any reason to stick
with my "glorified value" view of models anymore -- that was tied to
the "property bound to model/value" view.

If this is an acceptable version of the idea, it seems to me that we
have two main candidates:

  1. installFooModel() for making a model mirror an Attrib attribute.

  2. Use link() and 'update' events explicitly to implement the
     mirroring.

I'm still pretty open regarding which is better (or whether there are
other alternatives that are even better than these).

BTW: Could installFooModel be used to install more than 1 model? (The
link() scheme could.) This could make sense, but could also be a bit
weird... I guess the models would then be sync'ed with each other
through the Attrib object...

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