Hi Willem, I think you are basically on the right track - watch out for potential "event storms".
1) I think GWT team have put that note in docs 'cos so many examples use the simple inner class listener approach, so they are alerting people that if you have hundreds of them, well, things would slow down. 2) Yes, the given example violates information hiding/encapsulation principles, but I don't think they mean to suggest that a single "button bank" global is always "right". If you have, say, 10 main components in your application each with 10 clickable widgets (say buttons) then you could have 10 local versions of that pattern. That's 10 listeners, not 100, which is likely to be both efficient enough and conform to OO principles. A question of engineering balance basically. 3) If I were to nit pick about your example (and I mean really pick the nits) it would be that Grid already SourcesTableEvents, so you already know (if you listen for it) that a specific cell has been clicked, so listening for the button clicks is just doubling up the process - you could just as easily put a dumb image as the clickable and save on the button listener. regards gregor On Jan 2, 7:16 am, "[email protected]" <[email protected]> wrote: > *** Intro *** > The GWT FAQ entry "As the application grows, event listeners seem to > fire more slowly" .. > > http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=goog... > > .. recommends that instead of having a great number of separate widget > listeners, you let the EntryPoint derived class itself act as a > listener (one listener for many widgets), and that you store extra > information (eg. an index or id) about the widgets in a HashMap. There > is a warning about potential memory leaks if you don't remove objects > from this HashMap. For the finer details, click the above link. > > *** The application *** > Imagine a long list of books being displayed, with next to each book- > title an edit button. If you hit the edit button, you go to a > different screen allowing you to edit the synopsis of the book. > > For the implementation of this book-list screen I decided no to use > the HashMap strategy described in the above intro because of an > aversion to class variables, and also if the responsibility to remove > the objects from the HashMap to avoid memory leaks lies with the > developer, something will someday be overlooked, and you are on the > road to blowing up your memory ... > > So instead of storing the extra info (in this case the book-id) in the > HashMap, I chose to store the book-id in a custom button, which looks > like this: > > public class IdButton extends Button > { > private String id; > > public IdButton(String label, String id) > { > super(label); > this.id=id; > } > > public String getId() { .. } > public void setId(String id) { .. } > > } > > And then in the listener method of my main class, get the id from the > button to initiate the edit screen : > > public void onClick(Widget sender) > { > if (sender instanceof IdButton) > { > IdButton b=(IdButton)sender; > doEditBookSynopsis(b.getId()); > return; > } > .. > > } > > So the responsibility of cleaning up does not lie with the developer, > and potential memory leaks are avoided. > > *** The question *** > Is this a recommendable strategy ? Or are there better ways of doing > this? > > Regards > > Willem --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
