Hi,

> I assume
> that if you don't, you wind up with a memory leak since you accumulate
> listeners on non-existent events.

Your assumption is correct, and it's worse than you think: The
elements themselves will stay in memory, too, not just the handlers.
That can add up to a lot of memory consumption over time.

I usually do what Walter does: Delegate rather than watching the
specific elements. If I have a good reason to, I'll watch specific
elements, but then as a by-product of my application logic, I'll
release them before doing the update. But delegation is the default
answer.

HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com


On May 10, 9:22 pm, Walter Lee Davis <wa...@wdstudio.com> wrote:
> What I prefer to do is to add a single persistent observer to an  
> element that won't be destroyed during the life of the page, and then  
> delegate listening to that element. So if I had a list of things that  
> I wanted to observe, and one of the things I was doing was adding or  
> deleting those list items, what I would do is observe the UL that  
> holds them, since most events would bubble up from the children  
> (except certain form element events, like onChange).
>
> <ul id="list">
> <li id="elm_1">Element 1 <span class="delete">-</span></li>
> ... many more elements, all with similar structure
> </ul>
>
> $('list').observe('click',function(evt){
>         var elm = evt.findElement('span.delete');
>         if(elm){
>                 var id = elm.id.split(/_/).last();
>                 new Ajax.Request('delete.php',{
>                         parameters:{'id',id},
>                         onSuccess:function(transport){
>                                 elm.up('li').remove();
>                         }
>                 });
>         }
>
> });
>
> Obviously, you can handle many more elements and events inside the  
> same basic observer. If you like, you can use var elm = evt.element();  
> and then a switch statement to work out what the type of element  
> instigated the event and branch your logic that way.
>
> Walter
>
> On May 10, 2010, at 3:39 PM, Junkshops wrote:
>
>
>
>
>
> > Hi all,
>
> > I'm wondering what the appropriate thing to do is wrt event listeners
> > on elements that get replaced by an Ajax.Updater call or something
> > similar. It seems like a giant pain to have to run through all the sub
> > elements of the container you're updating and remove all the listeners
> > for every piece of AJAX on the site, but on the other hand I assume
> > that if you don't, you wind up with a memory leak since you accumulate
> > listeners on non-existent events.
>
> > Thanks in advance.
>
> > --
> > You received this message because you are subscribed to the Google  
> > Groups "Prototype & script.aculo.us" group.
> > To post to this group, send email to 
> > prototype-scriptaculous@googlegroups.com
> > .
> > To unsubscribe from this group, send email to 
> > prototype-scriptaculous+unsubscr...@googlegroups.com
> > .
> > For more options, visit this group 
> > athttp://groups.google.com/group/prototype-scriptaculous?hl=en
> > .
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Prototype & script.aculo.us" group.
> To post to this group, send email to prototype-scriptacul...@googlegroups.com.
> To unsubscribe from this group, send email to 
> prototype-scriptaculous+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/prototype-scriptaculous?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.

Reply via email to