Re: Subclassing DOM nodes

> Yes, event handlers are another way of adding behavior to a node.
>
> Note that you aren't limited to mutation events -- anything which
conformed
> to the Event interface can be dispatched through the DOM's event system.
In
> fact the example you use of a "Draw" event is almost certainly just such
an
> example; DrawEvent probably shouldn't be based on MutationEvent since it
> doesn't represent a change made to the document's content or structure.


Oh yeah - I forgot to say that without Creation Events/subclassing/
wrapping, the only way of adding event handlers transparently (eg.
for users to be unaware that there is additional behaviour) is to
propagate event listeners via DOMNodeInserted or
DOMNodeInsertedDocument ... which is my reason for saying
MutationEvent is an integral part of extensibile.  Mutation Event
allows a node to be initialised and uninitialised with behaviour as
it is added to or removed from the document.  Freeing clients
from the need to initialise each node when they create and insert
them is a good thing in my opinion because clients cannot be
trusted by a "value added" implementation to do the right thing in this
regard.

> At this time there are no Creation Events. It's an interesting thought...
> though I believe it could be done almost as easily by "wrappering" the
> DOM's existing factory methods, which might actually be a cleaner
solution.
> If you really think Creation Events are better, I can be persuaded to add
> them to the Open Issues List.


This may (or may not) be true for say adding behaviour by one
"value added" implementation in an OO language.

For example:

A visual tool subclasses Document and overrides all its factory methods
to support display of those nodes.  This is done by factory methods
adding event listeners to created nodes during factory method calls.

But:

+ there are languages that have no concept of subclassing.  For
these languages, you'd probably create a wrapper object - but the
danger is that some clients may get access to the underlying object
and create nodes that bypass initialisation.  DOM is full of methods
where you can get access to the underlying document object.
(eg. evey node has getOwnerDocument)  To block this every
node needs to be wrapped when they are created.  This is so
much overhead because it must be done regardless of whether
or not all nodes need additional behaviour.  For instance only
I want all elements to have added behaviour, but I will still
need to wrap all nodes because some client may use
ownerDocument.

+ adding further behaviour will often necessarily involving
adding another subclassing or wrapping layer.  In the case
of subclassing, this requires one "value-added" implementation
to be statically dependent on another, even though it does not
use any value added behaviour of the latter.  You be not able
to have a document with only one behaviour and another with
only the other behaviour and another with both behaviours.
(Ofcourse, you can resort to multiple inheritance - but not
everyone can or wants to go there)

+ in the case of subclassing I can only add behaviour
statically.  I can't have a document and then decide -
"I'm going to display this" and dynamically add behaviour
to the document.  Being able to iterate over all of a
document's nodes will be of assistance to the ability
of adding behaviour dynamically.

+ Events are language neutral - whether you have a flattened
prototyped language like javascript or an OO language like
C++/Java.  This is important for DOMs that have multiple
language bindings.  By implementing factory methods as
creation event aware means they clients using all language
bindings can extends and use extensions in a single consistent
manner.

My conclusion is that creation events, mutation events
and events generally are powerful tools for enabling
extensibility.

Extensibility has always been the reason for my interest
in events.

BTW, using events as an extensibility mechanism also
implies that it needs to be FAST.  If the event course of
extensibility is taken, there needs to be an investigation
on how performance of the event system can be improved.
I would not like to thing that the DOM Events API
intrinsically imposes a poor performance event system
on all DOM Event implementations.

Thanks

-John

Received on Wednesday, 11 October 2000 22:35:26 UTC