Re: I'm still here...

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

That's what I thought should be happening aswell. And this behaviour exists now in the push method. However, this didn't prove to suffice, and I needed to place if clauses in most of the back-end get/setFoo methods for anygui to even work.

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

Depends. For all practical purposes, whenever the model is relied upon for any data, after having been returned by proxy, any manipulation of the value that the model represents is managed by the model itself, which is attrictive for encapsulation purposes. So, if what you are suggesting is the following:

>>> foo = proxy.foo # where foo now contains the *value*, not the model

... then I must ask if the user should expect foo to be mutable in syncopation with the model, or that the value foo has been orphaned off at this point?

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

This is actually what the code does internally. Model only really overshadows value. So when the call to self.wrapper.pull(state) is performed, the attribute that model represents is now in state, and the model is updated according to that value, then state[prop] is replaced before the call to self.state.update(state), an extension to the lazy semantics in Attribs I guess...

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

I'm open to, just don't want to feel that I wasted time =).

>BTW: Could installFooModel be used to install more than 1 model? (The
>link() scheme could.) 

Well, by more that one model, do you mean more than one FooModel existing for foo at any given time? Wouldn't that be rediculous?

Howerver, if you meant that one model may represent more than one value at a time, yes. This is now possible, and Assignee handles multiple value sources.

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

Maybe I don't get where you want to go with this idea. Any examples?

--Dallas

__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/


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