Jason - You wrote: "The problem with the standard DOM EventListeners is that only one listener can be attached to an Element. The other problem is that a custom Widget may be required to listen for a sequence of low-level events in order to trigger a single high-level event (think MOUSEDOWN/UP/MOVE in relation to itemDraggedAndDropped())"
Yes! I agree totatlly! There are nothing BUT problems with the event model. So, with those shortcomings, why did they implement it that way? Like the 'roughian' man said so succinctly: "You can't addEventListener() to anything I'm aware of." That's my criticism in a nutshell! So, why didn't they implement it that way? Then they wouldn't have even NEEDED all those other (foolish) Listener- APIs with all their shortcomings! You wrote: "If you are extending the classes over and over again..." NO, I'm NOT! I don't like it that I need to! So, I refuse. In fact, what I found myself doing was to change my whole design (from what I had when I first implemented it in the old javascript-model) so that I am NOT implementing DBL-CLICK, because of the need to sub-class. [I found a thread a week ago or so, where someone found that in the soon-to-be released GWT 1.60, there was some refactoring of event-stuff, and I am hoping against hope that they were ripping out ALL the event-routines, and simplifying, but of course, they aren't. The community would be in an uproar. (Except for me.!) I'd welcome it with open-arms, as I have just one small app written in GWT, and would be more than happy to re-write all the event-stuff, if they were to redesign it totally.] On Dec 22, 3:04 am, Jason Morris <lem...@gmail.com> wrote: > The GWT event model is a close relation of the standard Java event model. > > The problem with the standard DOM EventListeners is that only one listener > can be attached to an > Element. The other problem is that a custom Widget may be required to listen > for a sequence of > low-level events in order to trigger a single high-level event (think > MOUSEDOWN/UP/MOVE in relation > to itemDraggedAndDropped()). > > So you hide the low-level events within Widget classes, which when they > receive the event can > trigger the collection of ClickListeners / MouseListeners / > MyFancyListenerNumber3. > > adding your "double-click" behavior to each > one in it's onBrowserEvent method, you're doing it wrong. The correct way is > to extend once, and > allow for adding any additional listeners (double-click, keyboard, etc.) to > the extended class > (which should trigger them in it's onBrowserEvent method). This way the event > handling logic remains > separated from the Widget itself. > > Also bare in mind Composite style classes (like a TabPanel) that want to turn > a Click event on a tab > into onBeforeTabSelected and onTabSelected for it's TabListeners. > > Hope that helps a bit. > > David H. Cook wrote: > > > The more code I implement and the more event-related APIs > > I look at in GWT, the more confused I get. After > > looking at complete examples about 'listeners' on website such as: > >http://examples.roughian.com/index.htm#Listeners~Summary > > or posts in this group, I conclude that the most general > > is an 'EventListener', because then I can get at ANY/ALL events > > that I might be interested in, as it's method gets 'Event e' > > as an input param. But, what seems to me like > > a real NEGATIVE is that I must 'extend' (sub-class) an object > > to use EventListener, right? > > > Now, if I only care about a 'click', then I do NOT need to extend, > > because there are 'clicklisteners', which listen for just ONE event > > type...'click'. But, if I want, say, 'double-click', well, there > > are NOT any 'double-click' listeners, so it seems that I'll need > > to use the more general EventListener. > > > That would be reasonable/acceptable if there was just > > ONE object that I wanted/needed to extend in a given app. > > But, let's say, I care about 'doubleclicks' from 3 different > > objects in the same app...anchors, tabs, and images. > > (Maybe not the best examples, but bear with me.) > > So, it seems that now I need to extend three objects, so I'll > > need 3 java classes (and thus, ...3 FILES...one class per file). > > [Some posts/examples mention 'widget builders' as a separate > > class of developer. But, I don't want to build new 'widgets'... > > I just want a write a simple app. > > > Somehow, the APIs seem to be making things unnecessarily 'complex', > > when I compare this to how easy it was to implement events > > in javascript language (before I started using GWT). And, its > > beginning to seem like the designers of the event-model/event-apis in > > GWT > > might have miss-designed the APIs?! (I wasn't around at the > > beginning, so I don't know how the event-APIs looked in version 1.00.) > > > Both the author of roughian website and other posters all seem to > > bemoan > > this need to extend, but all say it is necessary. For example, > > roughian > > says: > > > [Notes: > > This is something you should only use if you are subclassing a widget > > - it's not much use otherwise, > > you can't addEventListener() to anything I'm aware of. > > So, as a builder of widgets, you'd use this to pick up events and use > > them in ways > > that you can't do with the ordinarily supported event interfaces] > > > Clearly, I (and others?) must all be missing something. Where have I > > gone wrong? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
