Model.observeObject vs element.addEventListener()
johnjbarton
http://mdv.googlecode.com/svn/trunk/docs/model.html
the Model mechanism is a separable layer from the rest.
By itself this mechanism generalizes and shifts around the event
system.
Generalizes because any JS object can be observed (well to be sure,
models are observed and any JS object can have a model). Also
generalizes because the change event verbs come from a fixed set, [add/
delete, value-change], vs open set defined by the object.
Shifts around because now the observer thinks it is directly wired to
the object. In fact the model intervenes, but from the API point of
view the programmer thinks about the target object and the changes on
that object that are of interest. In the DOM event system on the other
hand, the programmer first thinks about the event, then about the
object. For example, the programmer first thinks about "load event"
then "target is document" or "click event" then "target is element".
Am I on the right track? Seems like this separate part could be used
in inter-module signalling quite apart from the template bits.
jjb
Rafael Weinstein
your use case.
On Tue, Aug 16, 2011 at 9:50 PM, johnjbarton
<johnj...@johnjbarton.com> wrote:
> As far as I can tell from reading,
> http://mdv.googlecode.com/svn/trunk/docs/model.html
> the Model mechanism is a separable layer from the rest.
>
> By itself this mechanism generalizes and shifts around the event
> system.
>
> Generalizes because any JS object can be observed (well to be sure,
> models are observed and any JS object can have a model). Also
Yes. Though, we have concluded that the ECMA Proxy.create() mechanism
currently isn't an net win as a mechanism for observing objects, and
we have "turned off" it's usage in our model abstraction. Now, the
model mechanism always just dirty checks all observed values.
Also, the API has changed somewhat. See the current Model.js file for details.
> generalizes because the change event verbs come from a fixed set, [add/
> delete, value-change], vs open set defined by the object.
This is presently true for Object and Array, but we feel that it may
be useful for application-defined objects to define their own verbs.
For instance, the implementation of the Array handler currently
"short-circuits" the stream of property accessed notifications, and
emits a single "splice" mutation "verb" for all array operations.
You can easily imagine that it would be useful for domain objects to
do something similar.
>
> Shifts around because now the observer thinks it is directly wired to
> the object. In fact the model intervenes, but from the API point of
The big change that has taken place here is that observers are now
notified asynchronously.
> view the programmer thinks about the target object and the changes on
> that object that are of interest. In the DOM event system on the other
> hand, the programmer first thinks about the event, then about the
> object. For example, the programmer first thinks about "load event"
> then "target is document" or "click event" then "target is element".
I'm not sure what you mean here. Can you explain more about this view?
>
> Am I on the right track? Seems like this separate part could be used
> in inter-module signalling quite apart from the template bits.
Possibly. The model abstraction continues to be completely separable
from the rest of MDV.
I'm curious to hear more about what you have in mind for inter-module signaling.
>
> jjb
>
John J Barton
I'm unsure why this is helpful, other than causing cascading changes
to be stacked on the event queue rather than the call stack.
>
>> view the programmer thinks about the target object and the changes on
>> that object that are of interest. In the DOM event system on the other
>> hand, the programmer first thinks about the event, then about the
>> object. For example, the programmer first thinks about "load event"
>> then "target is document" or "click event" then "target is element".
>
> I'm not sure what you mean here. Can you explain more about this view?
The issue here is encapsulation.
The API for the change handler in the MDV case are the properties of
the data proxied through the Model. This is very direct and simple,
but the developer of the |data| needs to treat the properties as API,
not implementation.
The API for the DOM event handler are event properties which may or
may not be proxies for the data. The event can have copies of values
so the handler cannot directly access the corresponding properties.
The event can have a property referring to an API which encapsulates
data.
>
>>
>> Am I on the right track? Seems like this separate part could be used
>> in inter-module signalling quite apart from the template bits.
>
> Possibly. The model abstraction continues to be completely separable
> from the rest of MDV.
And this part is similar to eg backbone.js right?
>
> I'm curious to hear more about what you have in mind for inter-module signaling.
I just mean change signaling unconnected to HTML. For example, an
editor may signal diffs to another tool, via events, eg:
http://orionhub.org/help/index.jsp?topic=%2Forg.eclipse.orion.doc.isv%2Fjsdoc%2Fsymbols%2Forion.textview.TextView.html
or it could use the model observe mechanism.
jjb
>
>>
>> jjb
>>
>