It makes sense. But why not traditional Model/View design when Model fires events and any subscriber (not necessary View) updates itself?
On Oct 7, 11:18 am, Thomas Broyer <t.bro...@gmail.com> wrote: > On Oct 7, 6:02 pm, ailinykh <ailin...@gmail.com> wrote: > > > Hello, everybody! > > I just looked into latest show case. CellList/Celltable work with > > ListDataProvider which is a class keeping all data. > > But it is aware about user interface - > > > dataProvider.addDataDisplay(display); > > > What a reason for that strange design? > > So that any modification made to the structure of the list (add / > remove / set) is reported in real-time to any "data display" attached > with the data provider. > You could very well use CellList/CellTable without a ListDataProvider, > and call setRowCount and setRowData on each of them "manually". The > goal of ListDataProvider is to save you these calls: you wrap a list > of objects in a ListDataProvider, you "register" your HasData(s) with > it and you work with the wrapped ListDataProvider#getList, so that any > add(), remove() or set() is instantly reflected in the HasData widgets > (i.e. it automatically calls setRowCount and setRowData for you; > including in response to a RangeChangeEvent fired by any of the > registered "data display"). -- 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-tool...@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.
