Re: MutationObserver - a better interface

Thanks, Rafael,

OK, this may be true for the technical (internal) implementation - but from 
an architectural perspective this technical implementation should be opaque 
to the user.

In fact, an observing action is always attached to a Node object (see 
current declaration for MutationObserver::observe()). You cannot process any 
observation without having a Node object attached to it.

So, it doesn’t matter how many MutationObserver objects are actually used 
behind the curtains. It should be up to the application implementer's 
decision only, how many private MutationObserver objects are used to fulfill 
the task of observing DOM changes or how the internal “Node <> 
CallBackFunction” dictionary is getting implemented.

>From a software architect’s point of view I believe the current design is 
too much technically driven and not being ideal. A good design would have 
emphasized on the abstract concept but not on a particular, current 
implementation.

I’ve read the discussion @ 
http://updates.html5rocks.com/2012/02/Detect-DOM-changes-with-Mutation-Observers 
, and I, too, personally believe the current interface to be, well, clumsy.

Axel Dahmen
www.axeldahmen.de




> "Rafael Weinstein" <rafaelw@google.com> schrieb im Newsbeitrag 
> news:CABMdHiRpgv5h8u6moewetg145nM6ivqtofbHNbLtq+vQUYQzhw@mail.gmail.com...
> MutationObservers can (and frequently do) observe multiple nodes (and 
> entire trees of node). The observer is neither conceptually nor concretely 
> connected to a specific node.
>
>
>
> > On Mon, Feb 3, 2014 at 9:08 AM, Axel Dahmen <brille1@hotmail.com> wrote:
> > I just read through the specification of MutationObserver.
> >
> > Well, I must admit that I actually don't see the point why 
> > MutationObserver is a dedicated object, being detached from any node in 
> > the document.
> >
> > The MutationObserver object is ALWAYS attached to a node. Whenever the 
> > node gets deleted, the MutationObserver becomes obsolete. So why isn't 
> > observe() just a member function of the Node object, returning the 
> > corresponding MutationObserver object?
> >
> >
> > Moreover, I don't understand why the callback function is being set at 
> > the constructor function of MutationObserver while the observation 
> > parameters are set at a separate function.
> >
> > From my perspective (from OO perspective) it would have made more sense 
> > to
omit the constructor and to add the MutationObserver.observe() member 
function to the Node interface. The callback parameter could have just been 
added to the MutationObserverInit class as an additional property.
> >
> >
> > That way, using the MutationObserver object would have looked similar to 
> > this:
> >
> >   {
> >      var observer = document.getElementById("MyNode").observe( 
> > {callback: myObserveFunc; childList: true; attributes: true; } );
> >
> >      observer.suspend(); // pause observation
> >      observer.continue(); // continue observation
> >
> >      observer.takeRecords(); // pop mutation records
> >      observer.disconnect(); // stop observation and invalidate observer 
> > object
> >   }
> >
> >
> > Is there any reason why this approach has not been taken?
> >
> > Axel Dahmen

Received on Saturday, 8 February 2014 17:27:42 UTC