On Jan 30, 1:44 pm, Ajay Garg <[email protected]> wrote:
> I have seen a "WrapperWidget" onClick() method get too crowded and
> cumbersome, as it listens to many widgets, that have been added over
> time as a part of project. Eventually, to change behaviour of say, a
> button, (which is being listened to by this "WrapperWidget"), one
> needs to hunt down in the "WrapperWidget"'s onClick() method, which
> may be located way up or way down the same class, or may be even
> somewhere else !!
Yes, that is a problem and is what I was getting at talking about
"granularity". If each main component (Composite) has one
ClickListener, then it's not much of a problem providing the component
isn't either too big or too small and hasn't got too many/few
responsibilities. Additionally it is sometimes convenient and more
readable to group event handling code for a component like that. The
new event system coming with 1.6 will make it much easier than it is
now to write readable and concise event handling code - I agree that
the current event system breaks down somewhat where multiple event
sources trigger multiple possible actions depending on various state
conditions.
>
> My only purpose to make Ebutton implement ClickListener, is to
> "tightly-couple" the button, and its "action-on-click"; so that it
> permits easy code view, and change, if and when required.
>
> And yes, I am - by this paradigm - avoiding the use of a "shared"
> clicklistener, at least for simple widgets like a button and a
> clicklistener.
Well, that's what the article I linked was warning you about. I can't
see that what you are proposing is that much different from the
standard anonymous ClickListener per button approach.
>
> Waiting for your thoughts ...
>
> On Jan 30, 6:00 pm, gregor <[email protected]> wrote:
>
> > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 -- 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 [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
-~----------~----~----~----~------~----~------~--~---
