Observing events on dynamic content.

[Richard Quadling]

Hi.

I know that I need to stop observing on elements before I destroy them
(say they are coming in via an AJAX connection).

I know one way of handling this is to not actually attach events to
dynamic content, but to the container and then use the bubbling
effect.

With that, the event handler for such a container may have several
different paths through the code, depending upon the event and the
element that triggered it.

I suppose if the generic event handler was nothing more than a switch
board, then the functions which is attached directly could remain as
they are.

Anyone know of anything else I should be aware of with this issue?

Regards,

Richard Quadling.

--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

[david]

Hi,

Why not relying on event delegation to a parent contener that will not
be delete or modify ??

btw, I thing the only problem is an excessive memory consuption. I did
not say/mean memory leak !!
There should not have more impact even.

--
david

[Richard Quadling]

2009/2/24 david <david.b...@gmail.com>:

I've put a container around the dynamic elements. This will have all
the event handlers attached. Most obvious really.

Thank you.

[Sidney]

I think you have just described the solution to a problem I am
experiencing, but I'm a bit too noob to understand quite to how to
implement it.

A basic eample (I have similar problems elsewhere): I have a div that
gets updated by ajax. The ajax request returns a list of data rows
with a delete button for each row. The oberserve code is also returned
in the response because it knows the id's of the delete buttons. I
*think* that when the refresh occurs the old observer handlers are
hanging around (memory is rising) and sometimes (perhaps on other
pages) the new content is not active i.e. the returned observers
sometimes don't take effect (that's on another page with buttons and
droppables).

Do you suggest something like: // Hope my rough psuedo code is
understandable
$$('#divid.del_button').each(removeObserver('click'));
update the div via ajax; (on success {
$$('#divid.del_button').observe( .... function to figure
out which delete button was clicked, work out correct row id, send to
delete action..)

Is this what you mean or have I got it totally wrong? If this is
correct, it looks like an elegent design pattern that would be
resuable:
1. clear * observers in the div
2. update div. On success {
2.1 add common obervers based on class to the div e.g. $$
('#divname.del_btn), $$('#divname.edit_btn), $$('#divname.view_btn) }

The 2nd problem that I infered to above, is when my ajax response
returns a droppables div, with code to attach the droppables observer,
sometimes that does not register. (I say "sometimes' because I have
droppables all over the place and haven't figured where this is a
consistent problem; sometimes they alreay exist on a page and other
times they get added and replaced dynamically).

Cheers.


On Feb 25, 8:13 pm, Richard Quadling <rquadl...@googlemail.com> wrote:
> 2009/2/24 david <david.brill...@gmail.com>:

[Richard Quadling]

As I am generating the content, I know my class and IDs that are going
to be present.

See http://pastie.org/400808 and http://pastie.org/400809 for cut down
versions of my code. Don't try to understand the specifics, but look
at the general flow.

Thi


2009/2/26 Sidney <AussieAl...@gmail.com>:

"Standing on the shoulders of some very clever giants."

[Radoslav Stankov]

You can do this little more simpler using this event delegation
methods: http://gist.github.com/66568

and then use this syntax:

$('elementId').delegate('click', '.some_selector', method);

note on the method -> "this" variable will point to the element who
match the selector

[Szymon Wilkołazki]

Radoslav Stankov wrote:
> You can do this little more simpler using this event delegation
> methods: http://gist.github.com/66568
>
> and then use this syntax:
>
> $('elementId').delegate('click', '.some_selector', method);
>

Seems nice. What are requirements of your scripts?
It uses Element#store and Element.#retrieve methods, but
they are undefined in our version of prototype (1.6.0.2).

Does your script require some extension?

And another question... Is that script public-domain, or you want it
to be distributed under some license? Which one? Or you have just
found it on the net and don't know?

Regards,
SWilk

[Radoslav Stankov]

Element#store / Element.#retrieve are in Prototypes github truck (this
version I currently use), but they are available from here
http://gist.github.com/53924 so one could used them until the new
prototype version arrives :)

as for my event-delegation implementation it is completely free, so
you can use it as you like :)

p.s. I, even hope that http://gist.github.com/66568 will make it to
prototype core, there is ticket open
http://prototype.lighthouseapp.com/projects/8886/tickets/435-eventdelegate-and-elementmethodsdelegate
I haven't seen any activity for it recently, but maybe the core
members are busy with their own work and with the new bug-fix release
of Prototype :)

Regards,
Radoslav Stankov

[Richard Quadling]

2009/2/27 Radoslav Stankov <RSta...@gmail.com>:

Aha. Event delegation is just a fancy name for bubbled events.

But in this specific example it won't work as the change event isn't
bubbled in IE. It seems.

I'd like to be proven wrong.

[Radoslav Stankov]

Yes this 'change' won't work on IE, so is submit / reset (... and more
of witch I can't remember right now)
I was thinking about a hacks for that, to 'simulate' such events: you
can do something like this ->

<pre>
$('tabRG_DynamicContainer').delegate('select', 'click', function(e){
var value = this.getValue();
if (Object.isUndefined(this._value)){
this._oldValue = value;
} else if (this._oldValue != value){
this._oldValue = value;
console.log('changed'); // or fire your own function
}
});
</pre>

This approach have some downfalls - change event is fired no only on
click events, and stopDelegating will not work well. But is goot
stating point, I think :)

[Richard Quadling]

2009/2/27 Radoslav Stankov <RSta...@gmail.com>:

Thank youl.