Yesterday, I was able to make a a decent start at a delegating event listener. The format
the listener ended up looking like:
attach_handler(list_el, 'click .delete', (event) {
print("[delete] ${event.target.parent.id}");
delete(event.target.parent.id, callback:() {
event.target.parent.remove();
});
});
As with jQuery delegated events, that is a fairly compact, literatesyntax. Under the list element (
list_el
), I establish a listener for clickevents on '.delete' elements. Since this is a delegated listener, this works for '.delete'
elements present now as well as any added later. The actual callback fired when the 'click
.delete' event is seen is a call to my XHR delete that, upon success, removes the parent LI
element.
That works, but it is a procedural approach. Ideally, I would like to add a delegated
listener something like:
list_el.on['click .delete'].add((event) {
print("[delete] ${event.target.parent.id}");
delete(event.target.parent.id, callback:() {
event.target.parent.remove();
});
});
If this were Ruby, I could re-open the Events class and redefine theon
getter:class Events { EventListenerList operator [](String type) { document.query }I cannot even compile that, however, without getting a redefinition error.
Hrm.. perhaps if I try with the implementation?
class EventsImplementation { EventListenerList operator [](String type) { document.query('#status').innerHTML = 'foo'; } }Well, that compiles, but it has no effect. The default implementation of the
on[]
operator still kicks in.Hrm... is it even possible to modify the EventsImplementation class (let alone override an existing method)? To test this out, I define the attach_handler() directly on the EventsImplementation class:
class EventsImplementation { attach_handler(event_handler, fn) { document.query('#status').innerHTML = 'foo'; } }Then, I invoke this with:
list_el.on.attach_handler('click .delete', (event) { print("[delete] ${event.target.parent.id}"); delete(event.target.parent.id, callback:() { event.target.parent.remove(); }); });Unfortunately, that compiles, but crashes in the browser.
I am stuck developing in Safari for iPad here, so I think it is best that I call it a night at this point. Tomorrow, I will switch to a desktop Dartium to attempt to see exactly where I am going wrong here.
Day #
No comments:
Post a Comment