[nebula-dev] Grid design

["Pete Davis" <pete@xxxxxxxxxxxxx>]

Chris,

My name is Pete Davis and I did the grid development in Mozart 1. Dan
pointed me to your grid and I've been looking over it (though not for very
long yet, so I'm probably missing a lot of stuff).

First of all, I just wanted to offer my assistance if you have any questions
with regards to grid type stuff. I haven't done much Java development at
all, but I've spent almost 3 years working on the Mozart 1 grid, so I have A
LOT of grid experience.

I do have some questions and comments on what I've seen so far...

It appears you're storing 3 different vectors of selections: Row selections,
Column selections, and cell selections.

I'm not entirely sure I get how the selection mechanism works. I see the
cellSelectionEnabled, so I assume that allows cell selection. Does that also
enable column selection?

There are advantages and disadvantages to having the selections separate. I
know the developers using the grid find it easier to deal with them that
way. But there are also some advantages to combining them into a homogenous
structure.

In the Moz1 grid (and we're using a commercial grid underneath, so we've
inherited their mechanism), there's the concept of a "Grid Range" which can
be column(s), row(s), or cell(s), or table and selection is simply a
collection of "Grid Range" objects. The grid range can be a single row or a
range of contiguous rows. It can a single cell or a rectangle of cells (must
be contiguous also), and so on and so forth.

One advantage is that you can perform set-style operations on it. You can do
unions of selections, intersections, "contains" style queries. For example,
Selection.AnyRangeContains(rowIndex, colIndex). That's a cheap query because
you simply go through your list of ranges (which is generally short, unless
you've got a ton of non-contiguous selections), and simply check to see if
the cell is contained in the bounds of any of the ranges.

Users of the grid like the ability to get the list of selected rows or
columns, so we offer that kind of functionality as well, by way of a wrapper
method that returns an array of row indices. It does make those type of
queries a little slower, but not much. You simply go through the list of
ranges and take all of type "row" and add an index for every row in the row
range.

Anyway, I just thought I'd mention it.

I also noticed you're doing the cell renderers on a column basis. 95% of the
time, this is all that's needed, but we've had some grids where people have
things turned 90 degrees: Say 2 columns of side-by-side data with different
types on each row. I don't recall what they have in there, but it's like Low
value, Mean value, High value and some other stuff like that where having
the data in columns like that, makes sense.

We've also had situations where people want to change the cell type based on
other contents of the row.

Is there any way to override the cell renderer of a particular cell? If not,
it might be useful.

Our grid is very event-driven. When painting cells, we fire off an event for
each cell before we paint it that allows people to override all sorts of
things. Colors, renderer, even the values, among a whole host of other
things.

Anyway, I'm not being critical at all. I'm simply throwing out some ideas...

I'll look it over some more. I've had enough time working on this grid that
there are a LOT of things I'd do differently if I had it to do over again.

Pete