Tommaso, I'm going to assume from what you've written here that you're trying to listen for events on elements that already exist on the page, and are not wrapped or created by any widget. If you take approach (1), the widget you use to wrap the element in question is doing (2) internally. And it does indeed clean up after itself as you say (which is the reason for a lot of the bookkeeping that widget subclasses perform). If you dig a bit into other Javascript libraries (Dojo, jQuery, etc.), you'll find that they all require you to do something similar, largely for the same reasons. jQuery's element removal function (last time I checked, at least) actually walks the entire DOM fragment of any removed element and nukes all its event handlers (not exactly fast, but effective). Some other libraries require you to explicitly dispose() a ui element (whatever they may call it) when it's no longer needed, and failure to do so will often result in a leak.
Side note on (2): You don't have to cast to user.Element -- that's vestigial (and will be deprecated at some point). Anything you can do with DOM.whatever() and user.Element, you can do more simply with dom.Element. All the static event-handling methods on the DOM class (like setEventListener(), etc.) have equivalents in the Event class that take dom.Elements as their arguments. The DOM static methods were created long before we had Overlay Types, and a big, ugly bag of static methods was the only way we could make it all go. You've probably already seen this, but if not, it might help illuminate the problem a bit further: http://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks Sorry I can't give you better news on the simplicity front. There's really no way to avoid the bookkeeping tax that browser memory leaks impose upon you, and we strove to make it as foolproof as possible, assuming you use widgets. One other possibility to consider (which may or may not apply to your situation). If you *do* have a widget wrapping some large DOM fragment (Tree comes to mind), then you can hook all events at the widget level, and handle them based upon the element at which they were actually targeted. This is the way most widgets work, and allows you to keep your initialization efficient (because you don't have to sink events on every single element -- you can just let them bubble up to the widget itself). Hope that helps, joel. On Thu, May 28, 2009 at 12:47 PM, Tommaso <[email protected]> wrote: > > I spoke with the GWT team at Google I/O and Miguel said this question > would be better answered here (by - I think - Joel). > > My company is very sensitive about SEO so we usually use GWT to add > behavior to existing elements. But we often run into trouble trying to > listen to events on existing HTML elements. > > In short: What's the recommended way to listen for events on > dom.client.Element objects? There seems to be two options: > > 1. Wrap it in the corresponding widget and use the widget's > addListener methods. > > DivElement element; > Label.wrap(element).addClickListener(...); > > This seems to work well when you can find a corresponding widget but > some things like HeadingElement don't seem to have any corresponding > widgets. This means that if we want to listen to events on a <h1> tag > we have to first wrap it in a div (with it's own id) which introduces > a new complications. > > 2. Cast the dom.client.Element to user.client.Element and use the > event listener methods on DOM. > > DOM.sinkEvent((com.google.gwt.user.client.Element) element.cast(), > Event.blah); > DOM.setEventListener((com.google.gwt.user.client.Element) element.cast > (),new EventListener(){blah}); > > This will work for any dom.client.Element but is ugly and leaks memory > in IE6 if you don't unregister your listeners when you're done. > > The company I work for started with 1 but have switched to 2 since > it's more generic. However it strikes me as odd that we have to go > through such contortions to perform an operation so basic to > javascript. Is there a option we're not seeing? > > If these really are the only options it seems to me that at the very > least the two event methods on DOM should have their argument's scope > expanded to accept the newer dom.client.Element objects. > > Besides this issue GWT has been a wonderful tool. Thanks for the help! > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
