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)
It's much better to start programming your "widgets" as autonomous objects, and keep handles to all your event handlers. Bill, your development pattern sounds like it's getting close to this, and you're at the point where you need to start thinking about garbage collection, especially if you want your applications to run smoothly in all browsers. 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. Your design pattern should start looking more like this... 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... 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); 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; 4. The request comes back from the server, resulting in a call to update the innerHTML property of MyControl's container div. After that call, the MyControl.controlLoaded() or setup() (or whatever you fancied in step 2) is called again, thus repeating the cycle... This was obviously just a very high level description of a design pattern, but I hope you get the idea. When you start developing truly robust, full blown applications in an AJAX context, your controls will need to be autonomous (unless you really want to have 1 huge script on your page that has to worry about wiring up all the new DOM elements that come and go), and they will need to clean themselves up. Garbage collection is important, and especially when dealing with self updating widgets that (most likely) have event handlers which are closures... Before I realized this, my applications would easily take IE to its knees (and most likely FF... keep in mind memory leaks are NOT, I repeat NOT, an IE only concern) The information transmitted in this electronic mail is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
