Have you considered using this version of TreeItem, which takes a Widget? http://google-web-toolkit.googlecode.com/svn/javadoc/2.3/com/google/gwt/user/client/ui/TreeItem.html#TreeItem(com.google.gwt.user.client.ui.Widget) http://google-web-toolkit.googlecode.com/svn/javadoc/2.3/com/google/gwt/user/client/ui/TreeItem.html#setWidget(com.google.gwt.user.client.ui.Widget)
The TreeItem isn't itself a Widget, but it can contain a Widget, and that contained Widget (think of it as a tree item renderer) can manage its own events. On Aug 10, 4:25 pm, lkcl <[email protected]> wrote: > On Aug 4, 5:36 pm, Jim Douglas <[email protected]> wrote: > > > The basic issue here is that TreeItems aren't Widgets, so (by design) > > they don't handle their own events. > > yeeesss... but that doesn't mean that child widgets of TreeItems > should be completely terminated from any possibility of having *their* > events handled, does it. > > > You'll want to review Tree to > > decide how best to manage your events. > > no, we won't [want to review Tree to decide how to best manage > events]. > > allow me to illustrate. > > what you're saying is that, instead of adding about 6 lines of code > (an implementation of onAttach and onDetach which does exactly what > Panel does - calls the onAttach and onDetach of all child widgets, so > that they get joined into the event handling infrastructure), you're > expecting developers to do this: > > * sub-class Tree and/or hook into Event Preview or onBrowserEvent > > * receive *all* events in Tree not just one or two, because you > cannot predict what events the child widgets will want. or, you have > to add duplicated infrastructure to receive and manage events that > somehow magically notify the containing Tree that actually, guys, you > wanted the event callback to be here but really it's gonna be down > here in this random Tree object which you should really have f***-all > knowledge of, it's miles down the hierarchy > > * do a massive recursive node-walk of all TreeItem no wait all > TreeItem _child_ objects, including *recursively* walking the child > objects of the TreeItem child objects in order to identify the GWT (or > in this case pyjamas) object that is associated with the DOM element > that received the event > > * add in infrastructure which duplicates existing code which is part > of the tried-and-tested GWT (or in this case pyjamas) codebase, > hooking *back* into the standard event handling system further up into > the child hierarchy. > > * using that duplicated code, as the correct object has been > identified (through the highly computationally expensive step 3 > above), call the relevant event callback. > > now, when it's put like that - which is what you're asking developers > to do - it does sound a bit like you're completely off your head, > please excuse me for pointing that out. > > 6 lines of code vs 400+ lines of code and a massive runtime > performance hit, duplicating functions that are built-in to web > browsers anyway _and_ duplicating functionality which already exists > in GWT (and pyjamas), there's no real comparison, is there? > > so - i invite you to look at this again, *without* the "static > mindset" of "TreeItems aren't Widgets" [implication being, there's no > way that the code can be either changed or fixed, and no improvements > will ever be made to it]. > > regarding "it's by design" - designs should only remain static if they > actually serve the purpose for which they were designed. in this > case, we have an actual real-world use case which demonstrates that > the design is, 'scuse me for saying it, shit. > > or, perhaps, i invite you to consider describing what possible > implications there could be to TreeItem having an onAttach and > onDetach. you'll find that even UIObject has onAttach and onDetach > (as stubs), so it's not like it's not possible to do this. > > the real question is: does adding onAttach or onDetach have any > unintended consequences / side-effects that need a workaround? for > example, what happens to up-down-left-right-enter key navigation, is > that affected? > > l. -- 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.
