-
Notifications
You must be signed in to change notification settings - Fork 0
Limitations
The dgrid package was designed primarily with AMD in mind; as such, it has been
tested primarily using the require and define APIs available in Dojo 1.7.
When using the legacy dojo.require method instead, loading dgrid/List will
not work without first loading dgrid.css. This is because otherwise the
xstyle/css plugin will resolve asynchronously, which is not suported by the
legacy loader. To use dgrid/List with dojo.require, make sure you have
<link rel="stylesheet" href="path/to/dgrid.css"> in your <head> before
loading dgrid/List.
This also applies for stylesheets loaded by specific mixins (such as dgrid/ColumnSet)
or extensions (such as dgrid/extensions/ColumnResizer).
Reusing a single column definition object between multiple grids (e.g.
var cols = {...}, gridA = new Grid({ columns: cols }), gridB = new Grid({ columns: cols }))
is not supported, and will not function properly. Always create a fresh columns
object for every grid you instantiate. This includes performing unique invocations
of column plugin functions for each grid.
If multiple grids in a single page are likely to use the same column layout, in order to avoid code repetition, you can create a function which returns the layout, but creates it every time it is called. For example:
function getColumns(){
return {
col1: editor({ label: "Column 1" }, "text", "dblclick"),
col2: { label: "Column 2", sortable: false },
...
};
}
var grid = new Grid({
columns: getColumns(),
...
}, "grid");
var secondGrid = new Grid({
columns: getColumns(),
...
}, "secondGrid");Currently, if both formatter and renderCell are defined on a column definition
object, formatter takes precedence entirely. This particularly gets in
the way of column plugins, for which renderCell tends to play a pivotal role.
This issue will be investigated further.