Well, buttons don't implement ClickListener, they implement SourcesClickEvents (amongst other things). It looks to me like your EButton would effectively be listening for it's own click events? So each EButton would have to handle its own action independently, and you could not then by definition share a ClickListener between multiple buttons. I can't at the moment see what you are trying to achieve with this line of reasoning.
On Jan 30, 12:30 pm, Ajay Garg <ajaygargn...@gmail.com> wrote: > Also, that might also eliminate the "Memory Leak" problem, as stated > athttp://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=goog... > > On Jan 30, 5:27 pm, Ajay Garg <ajaygargn...@gmail.com> wrote: > > > Thanks Gregor. > > > Seeing the link, it says that creating an anonymous clicklistener > > class per widget is a performance overhead. This repops the question - > > what if the Button itself is extended to implement ClickListener to > > make an abstract class EButton, and making onClick abstract. Thus, > > whenever a new EButton is instantiated, the user defines the onClick > > method. ( This is case 3 of my first post. ) > > > This keeps the encapsulation, as well causes no extra class > > instantiation. > > > Your thoughts .. ?? > > > On Jan 30, 4:39 pm, gregor <greg.power...@googlemail.com> wrote: > > > > Hi Ajay, > > > > A common reason for using a single event listener across many links/ > > > buttons etc is performance. See: > > > >http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=goog... > > > > As Danox says, there is no one best approach, it depends on the > > > application type and size. The main issues are encapsulation, > > > decoupling, and granularity. A good unit of granularity is, say, a > > > Composite panel that performs a main task in your UI and may have > > > several widgets inside it including a number of links/buttons. > > > > Within the Composite all the buttons/links etc are visible, so a > > > single ClickListener instance can service them all, e.g. { > > > > public void onClick(Widget sender) { > > > if (sender==b1) { > > > doSomething(..) > > > else if (sender==b2) { > > > changeListeners.fireChange(..); > > > ......// etc > > > > } > > > > Technically you can make a second main Composite component implement > > > ClickListener and register it with a button buried in Composite 1. I > > > think that is probably a bit too fine grained and involves Composite 2 > > > knowing about Composite 1 internals (breaks encapsulation). I prefer > > > to implement events visible to other main components at the Composite > > > level. So Composite 2 registers with Composite 1, and Composite 1 > > > mediates between Composite 2 and the button concerned. > > > > regards > > > gregor > > > > On Jan 30, 6:15 am, Ajay Garg <ajaygargn...@gmail.com> wrote: > > > > > Thanks danox for your viewpoint. > > > > > However, just curious, isn't case 2 doable as a case 1; i.e. after the > > > > button is clicked, it calls a method elsewhere, which may then > > > > delegate to a RPC ... > > > > > Ajay Garg > > > > > On Jan 30, 10:14 am, danox <danoxs...@gmail.com> wrote: > > > > > > I'm not sure that there is a recommended way. Its really up to you or > > > > > the coding style of your team. > > > > > > I tend to use 1. for most simple implementations (e.g. if I want a > > > > > button click to call a method elsewhere) and 2. for more complex > > > > > implementations (e.g. if I am adding a series of buttons > > > > > programmatically, each of which will trigger an RPC call with unique > > > > > parameters when clicked). > > > > > > I've never used 3 and it doesn't strike me as a great way to do it, > > > > > but that's just me. > > > > > > On Jan 30, 3:38 pm, Ajay Garg <ajaygargn...@gmail.com> wrote: > > > > > > > Right, and so that brings to the query in my first post :: What is > > > > > > the > > > > > > recommended way to attach a clicklistener to simple widgets like > > > > > > Button and Hyperlink :: > > > > > > > 1. Let a Button be listened by itself ? > > > > > > 2. Let a Button be listened by a bigger widget (eg. DeckPanel, > > > > > > HorizontalPanel ..) encapsulating it? > > > > > > 3. Let a Button be listened by the module of which it is a part? > > > > > > > Ajay Garg > > > > > > > On Jan 30, 9:08 am, ajay jetti <programmera...@gmail.com> wrote: > > > > > > > > The Answer to second question depends on the scenario , but > > > > > > > multiple > > > > > > > listners on a single button? i din know if that is possible- Hide > > > > > > > quoted text - > > > > > > - Show quoted text -- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
