If you do not use or case about cell based Widgets (formerly referred to as enterprise widgets), you can ignore this email.
There are two pending proposals to the Cell API. Both are relatively straightforward and arise from use cases while creating the demos. * Cell#getConsumedEvents() The first proposal is that we should replace Cell#consumesEvents() with Cell#getConsumedEvents(). This allows the container widget to only sink the events that the Cells rely on, and to pass the Cells only the events they consume. We've planned this change from the beginning, but haven't really thought about the API until now. https://wave.google.com/wave/#restored:wave:googlewave.com%252Fw%252BDbKnvP3NA * * * * * *Cell#handlesSelection()* This second proposal is to add the method Cell#handlesSelection(), which returns a boolean indicating that the Cell updates the selection model. If true, the container widget will not automatically update the selection model on mouse events. Currently, mouse selection is not consistent between widgets. CellList checks if the Cell consumes events, which isn't really related to selection. CellTable has a setter to enable/disable selection. The problem with both of these approaches is that its a little confusing for the user as to why selection is on or off. By adding a method directly to Cell, it becomes much clearer when the widgets should handle selection and when the Cell should handle selection. https://wave.google.com/wave/#restored:wave:googlewave.com%252Fw%252BUB51B1NjA * * Thanks, John LaBanca [email protected] -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
