On Fri, Mar 31, 2006 at 10:22:56AM -0600, Ryan Gahl wrote: > But... Behavior does not address the problem of disposing of the already > created event handlers (which are very often closures, therefore big > potential for memory leaks)
Which is why I've been moving away from Behavior. Although, I have not looked at the new version yet. > Every time you send a request that updates the elements in your div, if > you don't first clean up the event handlers that were setup in the > previous elements... you leave your application with a memory leak > potential, big time. Sure seems like something javascript should deal with. Closures are tough, but perhaps some kind of "weak reference" support could solve that. If an element is destroyed sure seems like javascript should figure out how to free up memory. Do these memory leaks persist after a full page reload? The horrors. > Your design pattern should start looking more like this... Thanks very much for this. I suspect it will take me a few passes to understand it. Do you happen to have a small working example? I admit to not fully understanding the object model in javascript, yet. I still find "this" confusing. Sometimes it's the element, sometimes it's the object (instance?). > 1. MyControl (div) loads for the first time. The DOM elements associated > with MyControl have unique IDs that are prepended with MyControl's > identifier. This will allow you to start loading in multiple controls of > the same type more easily... By scanning the DOM looking for the prefix on the ids? > 2. After the HTML is loaded, MyControl sets up its own DOM event > handlers (autonomous widget) in a method called something like > controlLoaded() or setup() or whatever you fancy. When MyControl does > this, the event handlers are stored in member variables, and so are the > DOM element references -- this allows for proper cleanup before the next > server request to update the widget. Something like this... > > this.someLink = $(MyControl.id + "_someLink"); > this.someLink_ClickHandler = > this.someLinkClicked.bindAsEventListener(this); > Event.observe(this.someLink, "click", this.someLink_ClickHandler); bindAsEventListener() means that when the event fires you get the *instance* of the object in "this", correct? Is there any worry that bindAsEventListener(), as a closure, will also leak? > 3. Some application level event occurs which triggers MyControl to send > a request (by itself, remember it's an autonomous widget) to the server > to be refreshed. Before it sends the request, MyControl is responsible > for cleaning up the resources (memory) that it has a hold of. This means > getting rid of the event handlers for all of it's DOM elements (which > will be overwritten with new ones). Something like this... > > Event.stopObserving(this.someLink, "click", this.someLink_ClickHandler); > this.someLink_ClickHandler = null; > this.someLink = null; Here's where I get lost. The event fires and then I free up the event bound to that element. Where's the list of other events to free up before starting the ajax call? Thanks very much for the help, -- Bill Moseley [EMAIL PROTECTED] _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
