It’s actually somewhat strange to set the cell like this in the general case… or certainly in ListBox style use-cases where the GridModel is actually backed by some other source of data.
There is kind of two different ways to use the GridModel.
you are going to shove values into it directly and store them (like ArrayGridModel). In that case, the ‘existing’ parameter can probably be ignored.
you are actually retrieving a transformation of some underlying data structure that is not panels. In that case, you will never call setCell() because the cells are really determined by some underlying data structure. In the case, the caller provides the existing value they got the last time they called getCell() when they call getCell()… so you might get away without creating a new one.
ListBox is a good example of this second case.
GridPanel takes a GridModel and it already keeps track of the Panels that it asked for because it shoves them into a container and can retrieve them whenever. So when getCell() is called it will pass in the Panel it got last time. Most uses of GridPanel will not be just shoving Panels into the model… they probably created their own GridModel that is adapting something else to a Panel of some kind.
I was using this one, an yes got notice that existing panel is being ignored when getting cell.
I soon run to limitation with this approach.
Aha, now understanding the GridModelDelegate in ListBox, so using this approach we have Model and View separated. we prepare a model of type T ( for example InventoryItem) and we create a view for it by writing an specific CellRenderer for it.
Then grid panel will then auto call for cell renderer in refreshGrid() by passing the existing panel (which is coming from it’s layout (SpringGridLayout) ).