Re: MutationObserver - a better interface

Moreover: If there is a MutationObserver attached to a node and if that node 
gets deleted from the DOM, the corresponding observer must automatically 
disconnect and the internal “Node <> CallBackFunction” entry must be removed 
from the MutationObserver's internal dictionary.

So it would have made very much sense to better have the MutationObserver 
interface defined as I have suggested in my first mail below.

But that ship's already sailing, I guess?

Regards,
Axel Dahmen


--
"Axel Dahmen"  schrieb im Newsbeitrag news:ld5pcj$pjh$1@ger.gmane.org...

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 Tuesday, 11 February 2014 15:39:57 UTC