New in 1.1

This widget is a container partitioned into up to five regions: left (or leading), right (or trailing), top, and bottom with a mandatory center to fill in any remaining space. Each edge region may have an optional splitter user interface for manual resizing. Note that there can be at most one child marked for each region.

InlineEditBox is best described as a behavior on some text on the page, such that clicking that text brings up an editor, and when the text is saved, the screen is reverted to it's original state (but with the new text). The editor is created on-demand, so as to not slow down page load.

Grouping data for summarization requires a simple strategy. We will calculate a summary subrow for every row in the table, then just hide the ones not on a group boundary. So here is some (boring!) numeric data:

As we alluded to in the last few pages, selection and cell editing is pointless without some kind of background processing. So how do you hook code into these places? Through Dojo's event model, of course!

Editing Changes

If you're using a writable dojo.data datastore, you simply hook your procedures into the dojo.data Notification API. Suppose in our running example, we make the Description field editable:

Cell Styles

Fixed styles that apply to all cells of a column are settable in the view. The properties you need:

Up until now, we've showed grid contents in view mode. Now, let's add some interactivity.

An editable cell is handled by a cell editor. To make a cell editable, you simply specify the cell editor class in the column definition. Here is a part of the view definition code in /dojoroot/dojox/grid/tests/test_edit.html.

That's nice so far. The column header stays in place while the user scrolls down, making them easy to identify. Can we apply to that rows as well?

Yup. You can make row headers that stay in place and act as selection points.. What's more, you can split your grid into arbitrary scrollable sections that can stay in sync or scroll independently. You do this by gluing more than one view into a structure.

Grid neatly separates the model from the view in its MVC implementation. We just covered the model. Now we'll cover the view - that is, everything used to display the model elements.

In the world of Grid, the structure is the largest unit. Structures are composed of views. Views are composed of cells (what we normally think of as a column). We'll start at this lowest level first. As we've seen a cell is defined by a JavaScript object like this:

Grid Sizing

By default, the grid fits exactly in the parent DOM node provided for it. If all of the rows do not fit, a vertical scroll bar appears. Likewise, if all the columns don't fit, the horizontal scroll bar appears. Nothing surprising there.

The following properties resize the grid to fit all of the columns. In essence, setting either of these makes the appropriate scroll bar disappear.