Unfortunately this document needs to be updated. But I'm interested in
your use case.
On Tue, Aug 16, 2011 at 9:50 PM, johnjbarton
<johnjbar
...@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.
