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

Or are we absolutely trying to avoid this?

>Another remark: the __setattr__ we are referring here is on the Proxy, the
>setter is OTOH a Wrapper method.
>At  the moment Attrib knows nothing about wrappers, it calls Proxy.push/pull
>that know about wrapper.

This is fine, as the check for type Model resolves issues associated with whether or not to push or pull. It circumvents it by this means. Basically, all management of the property is delegated to the model, so it becomes fairly hands-off for the Proxy from that point on. The only other problem that I can see with this is if the Wrapper ever decides to push state to the Proxy, instead of the Proxy pulling it exclusively, which would kill the model. Perhaps this could be better handled by my model-delegate proposal. Or perhaps not... I have to look at it in more depth.


>But it seems, we have still a problem with retrieving comp.text ...
>
>because for that we have to pull  the text value from the widget (I mean the
>backend/toolkit widget) and then set it in the model/in state, 

I'm sorry, I didn't post this bit in the sequence, as I thought that it was fairly inherent. It goes more or less along the lines of retrieving both the getter and setter methods when assigning the property to the Model, and then having the Model call the getter directly on the wrapper. One problem with this, however, is that there is the reference issue, which plainly sucks =). But, and forgive me for belabouring, I think that the delegate installation method might solve this one too by having direct management over this portion of the Proxy's interaction with the Wrapper. But, then again, it's late, and I am sure that I am missing something here =).

>but that should
>then broadcast the corresponding change-event to all handlers but not to setter
>one because that would be still a spurious call (vs. the spurious push call
>with the other approach).

Hmmm... I missed something here. I'm not seeing the connection you are making with *getting* text and *changing* text in these last two comments. I was under the impression that these were two mutually exclusive functions. However, I do see your point that Wrapper calling push on Proxy is sort of self defeating for the Model. Perhaps this is again yelling, "delegation!!" ?!?


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

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.

What do you think?

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