On Sat, Oct 10, 2009 at 4:06 AM, Amir Kashani <[email protected]> wrote:
> > On Fri, Oct 9, 2009 at 8:10 PM, Ray Ryan <[email protected]> wrote: > >> But allocating a widget per row isn't a great plan anyway, it won't scale. >> UiBinder is not a renderer--it's for laying out assemblies of widgets, not >> iterating over data to build them. We don't yet have a tool for that. (Or >> were you thinking in terms of pure DOM objects?) >> > I certainly don't _want_ a Widget per row. A pure DOM hierarchy works fine > as long as no events or "enhanced" functionality is required. More often > than not, however, when displaying a grid of data, there's need for user > interaction, meaning at least some widgets. With UiBinder, this mean a > widget per row. (I suppose it could all be DOM based and the root element > from any required widget could be attached manually. This is complicated and > asking for memory-leaks though) > > Anyway, despite the bug in HTMLPanel, I guess the advice is: don't do this > and use a one of the table/grid widgets to dynamically allocate rows? > When you want to handle events on a large collection of child objects, you can always aggregate the DOM event handling in the Widget that contains them all. The tree and table widgets work this way -- it's a bit of extra work, but it's a *lot* more efficient. Not only can you avoid creating widgets for all the children, but you don't even have to add event handlers to them in most cases -- just let the events bubble up to the widget and sort them out there (if you want focus/blur events, you'll still need to sink them on each element, because they don't bubble). --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
