Comment by andrew.pietsch:
There's a few things. Firstly I would have liked the ability intercept and
cancel a selection event (like GWTs `TabPanel` does it). i.e.
`ListSelectionModel implements HasBeforeSelectionHandlers` or something
equivalent.
Also Swings `ListSelectionModel` lacks the convenience method `int[]
getSelectedIndices()`. Some of this behaviour was implemented in JTable
(see `JTable.getSelectedRows()`) but as someone who likes passive views I
had to replicate this basic behaviour in my own model layer, not hard to
do, but a pain to have to do it.
I would have also liked a `setSelectedIndicies(int[])` or equivalent, but
this has issues with how the lead and anchor are calclated. Which leads to
the fact that `ListSelectionModel` didn't have the notion of a
`SelectionState` (that encapsulated the everyhing including lead and anchor
etc). So in the case where you're restoring selection state from an undo
history you have to track all the bits and restore it yourself. I.e. there
was no ability to get and restore the selection state as a memento.
So off the top of my head I would have liked the `SelectionModel` to define
the selection in terms of a `SelectionState` but to also provide
convenience methods for manipulation E.g something possibly like:
{{{
// main methods for changing and querying the selection
setSelectionState(SelectionState)
SelectionState getSelectionState()
// but also provide convenience methods with meaningful defaults for
lead/anchor etc
setSelectedIndex(int) // simple single selection case
setSelectedIndicies(int[]) // either single interval or multiple interval
addSelectionInterval(int start, int end)
... // etc
}}}
And `SelectionState` would have methods like:
{{{
// convenience methods..
int getSelectedIndex()
int[] getSelectedIndicies()
boolean containsIndex(int)
// and the hard core methods mostly for the widgets
int getAnchorIndex()
int getLeadIndex()
int getMinIndex()
... // etc
}}}
In this case the `SelectionHandler` and `BeforeSelectionHandler` would
recieve the `SelectionState` in the selection event.
I'm not sure what approach I would have preferred for handling single,
single interval, multiple interval selection modes i.e. one size fits all,
different implementations of `SelectionState` or different models all with
or without builder apis. I think one size fits all is probably best if it
can be kept clean and elegant.
And finally (but probably most importantly) it would have been nice if the
class documentation contained an "Understanding Selection" blurb that
covered the concepts (min,max,lead,anchor etc) in one place and with
examples of how they change as intervals come and go.
Sorry for the length...
Cheers
For more information:
http://code.google.com/p/google-web-toolkit/wiki/DataBackedWidgetsDesign
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
