Re: [DOM4] EventTarget as first class citizen

On Wed, Feb 29, 2012 at 9:59 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wed, Feb 29, 2012 at 5:41 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
>> On Wed, Feb 29, 2012 at 8:25 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> On Wed, Feb 29, 2012 at 3:24 PM, Anne van Kesteren <annevk@opera.com> wrote:
>>>> On Mon, 27 Feb 2012 15:18:55 +0100, Marcos Caceres <w3c@marcosc.com> wrote:
>>>>>
>>>>> On Thursday, February 23, 2012 at 3:18 PM, Jonas Sicking wrote:
>>>>>>
>>>>>> I think the way we should do this is to enable instantiating
>>>>>> EventTarget objects using an EventTarget ctor. This won't give you a
>>>>>> neato extension syntax, but I think we'll have to rely on ES.next for
>>>>>> that. Before ecma-script has a better solution you can always
>>>>>> monkeypatch the object.
>>>>>>
>>>>>> So something like:
>>>>>> a = new EventTarget();
>>>>>> b = new EventTarget(a); // a is the parent in the target chain
>>>>>>
>>>>>> should be doable. I don't know if we need a way to modify the parent
>>>>>> chain after construction. It's somewhat complex to allow this while
>>>>>> still preventing cycles from being created.
>>>>>
>>>>> It would be great to see something like the above.
>>>>
>>>> Unless someone explains how that graph model applies to the tree model we
>>>> have now and what the processing model around it will, I'm not sure this
>>>> will go anywhere.
>>>
>>> Sorry, I guess I left out that critical part.
>>>
>>> The simplest solution would be that for something like
>>>
>>> b = new EventTarget(a);
>>>
>>> say that "a" must be an object created using the EventTarget
>>> constructor. As long as we don't have syntax for modifying the "event
>>> target parent" there would be no way of constructing arbitrary graphs.
>>> Only trees would be constructable. That's what I meant with the part
>>> about not being able to modify the parent in the original email.
>>>
>>> A more complex solution would also allow modifying the target-chain
>>> parent. For something like
>>> b.eventTargetParent = a;
>>
>> What if we just make it traverse using parentNode accessor? This way,
>> the current event dispatch can be formulated consistently for DOM and
>> non-DOM objects.
>
> Not sure I understand the proposal. Are you saying we should introduce
> a .parentNode property on the new EventTarget object? Would it be
> different in anything other than name from what I proposed above?

Nope. Other than name, it's exactly the same.

>
> / Jonas

Received on Wednesday, 29 February 2012 18:03:25 UTC