Re: Release 0.2a0?

Samuele Pedroni <[email protected]>:
>
> 
> > What major obstacles remain before such a pre-release? Dallas: How are
> > the models coming along?

Just a quick note about models: If they are proving problematic,
perhaps we should leave them out of 0.2a0 too? (I'm just interested in
getting something out that works, as soon as possible.)

It seems that there may be more than one challenge in updating these
for 0.2. (E.g. getting them to work properly with push/pull; I seem to
recall something about the in-place modification in pull() being
broken or not implemented?)

> Am I seeing right that the infinite recursion avoidance mechanism in
> event send is not enough to avoid spurious push with models?

Hm... That may be.

> A) if prop1 of a component is bound to model mod modifying prop1 will
> 
> [Attrib.modify]
> 
> change value of mod
>   this will trigger a change event
>    one of the handlers is: push  prop1 for comp [1]
>    ... other handlers ...
> push prop1 [2, aggregate push at the end of Attrib.modify]
> 
> Is this correct ?

Hm. Modifying the model shouldn't affect the component that holds it
as an attribute in any other way than the normal route. Per default,
the component should not observe the model. (Maybe I'm just not
following your argument here...)

> We could avoid to add the names of props bound to models in the name list
> passed in [2], but when changing more than one single prop, the best thing
> would be to avoid to call [1].
> 
> B) retrieving comp.prop1 can pull the value from the widget, then if prop1 is
> bound to a modal its value is (should be) changed but this would trigger a
> spurious push...

Why? I don't see why modifying the model should trigger a push? Of
course modify() calls push, but that's beside the point. My view is
that using foo.rawModify(bar=fnord) should not call foo.push(), even
if bar is a model. The idea with models is that *other* objects are
allowed to listen in on their state. If the component itself wants to
do so it is allowed to of course, but if it links this listening to
push, then a "spurious" push is exactly what one would expect.

(Though I still have a sneaking suspicion that I'm not getting the
point here :)

> It seems we need a mechanism to identify handlers and a way to send
> an event but ignoring some specified handlers.

If indeed we do, this might perhaps be related to the tag system
proposed by Alex (and others). But I'm still not quite sure why we
need it... I suspect we might need to clarify (if nothing else, then
for my benefit ;) how we expect models to behave.

> Samuele.

-- 
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org


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