Comment by [email protected]:
@gg: Thanks -- we definitely need to look at glazed lists when thinking
about how table models are defined.
@andres: We certainly need to experiment with the class relationships, and
this is by no means final. The broad idea, however, is that the views are
essentially passive -- they express a "range of interest" (e.g., a
row-range in the case of a list or table) that the model then pushes into
them asynchronously. This allows for several specific benefits:
- It's inherently asynchronous, making it easier to fetch data as necessary.
- It allows the model to send new data to a view whenever it's available
(not just when requested)
- This is important for server-pushed data.
- It allows the model to quickly provide whatever data it has available,
then send the rest later. For example, if a list needs rows [0, 10], and
[0, 5] are cached, the model can provide the first five, request the rest,
and provide them when they're available.
It's also important to note that this is *not* meant to be a fully-abstract
MV[CP] system -- it's just meant to solve the problem of getting data
efficiently and asynchronously to large lists, trees, and tables. In that
sense it's more like Swing's JTable/TableModel. A system with its own
MV[CP] pattern implementation could reasonably treat the pair as a single
logical unit.
For more information:
http://code.google.com/p/google-web-toolkit/wiki/DataBackedWidgetsDesign
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
