Re: I'm still here...

Samuele Pedroni <[email protected]>:
>
[snip]
> > 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?

I think Dallas had some good points here -- manipulating the returned
value from an attribute wouldn't make any difference to the Component,
and that might be misleading. So under this scheme, Dallas's current
implementation might be the most intuitive after all (even though at
first impression it struck me as quite baffling <wink>).

So... With the propert-"containing"-model approach, it seems that
returning a model on access, but using values on assignment, is the
best solution (although I may need a few days to accustom myself to it
;)

The alternative (I'm working with two main alternatives here -- if
there are more, please correct me), i.e. the decoupled-observer
approach can be maintained even with copy semantics in the attributes.
This may potentially be quite simple -- a Component is modified only
by assigning to its attributes, or by using the utility method set(),
which also assigns to its attributes (or possibly making plain
accessors setFoo and getFoo etc. available -- that ought to make Greg
happy ;). Also, the Component does not modify anything -- to get
modified values, you again have to access the attributes or use an
accessor (get(...) anyone?).

This makes Components quite simple (and similar to Jython widgets, I
think). The only addition needed to implement MVC is to make all
components send a 'modified' (or something) event when they are
modified by the user.

Note that an approach like this might allow us to simplify the
internals and the front-end/back-end interface drastically too. We
might no longer need push/pull... We might even give more or less
direct access to the getters/setters in the back-end wrapper...
In-place modification was one of the main reasons for push/pull, and
if we drop that (which I think well we might) we might end up with an
architecture that is much easier to understand, explain, and maintain.
We'd have to be careful not to go overboard on it, though, since some
separation and encapsulation between Proxies and Wrappers is probably
a good thing -- using only Wrappers seems a bit too simple. (Although,
at the moment, I'm not sure I can point to why it wouldn't work...
Hm.)

Hm.... <scratches head>

> the whole question is what in the presence of a model should
> 
> L=[...]
> comp.items=L
> L.insert()
> comp.push('items')
> 
> do get what I presume you mean with mirror you need the above comp.items=L to
> have reference-rebinding semantics, whereas a changed model modifying items
> could do that with copy semantics or throw L away and replace the reference,
> depending on the choice you have different behaviors?

I'm not sure I quite followed that sentence... But I hope I've
explained the two alternatives I (currently) see above.

[snip]
> > 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...
> 
> I would vote for weird, rather weird :).

?-)

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