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.
