Hypergrid v2.1.2

Please refer primarily to the Release Notes: v2.1.0 wiki page.

In addition, this v2.1.2 follow-up release fixes a few bugs in rarely used features:

• Internal: Reorganized the way the new deferred behavior changes were implemented to make sure they are resolved at the next grid render.
• Internal: Improvements to the new Registry class.
• "Dev Testbench" demo: Updated rowProperties to rowStripes in the demo.
• Fixed an error when stringifying state containing the new row properties.
• Restored the the deprecation described in the v2.1.0 release notes under the heading treeColumnIndex and rowColumnIndex. (This was a rarely used feature but eliminating it was premature because it was a breaking change.)

This release has been published as a module to the npm registry.

A bundled build of 2.1.2 is available on the CDN.

Hypergrid v2.1.0

Please see the Release Notes: v2.1.0 wiki page.

Hypergrid v2.0.2

Minor Fixes

This release exposes a registry of fin.Hypergrid.datamodels to the global namespace.

This also fixes grid.reset and issue with the scrollBoundaries when applying a theme

Hypergrid v2.0.1

Please see the Release Notes: v2.0.1 wiki page.

Hypergrid alpha release (v2.0.0-alpha)

This release adds a theme registry.

Also fixes issue #515.

Hypergrid v1.4.2-alpha

This is an alpha release.

Instantiating with state

This alpha release adds options.state to the Hypergrid constructor, which means that if you have your state object handy, you can now hand it to the constructor instead of called grid.loadState(state) later on.

promiseToLoadDataAndState.then(function(data, state) {
    var = new Hypergrid({ data: data, state: state });
});

Caveat: If your state object includes column or row properties, be sure to set data first via options.data, as shown above.

Documentation

See the almost-complete wiki, Persisting Grid State for details.

Hypergrid v1.4.1-alpha

This is an alpha release.

Persisting state

This alpha release adds Hypergrid.prototype.loadSate and .saveState for persisting grid state in serialized form via JSON.

Dcoumentation

Please see the forth-coming wiki, Persisting Grid State for details.

Hypergrid 1.3

Hypergrid Module

ClearState Resets griid.properties on initialization. Non internal listeners get cleared on reset

setData will reshape the grid if a new schema is passed, or one wasn’t and it doesn’t have any cached (in which case, it will derive a schema). If setData is called with just data and a schema is already available the grid without changing column definitions

Parameter change: setHoverCell(point) -> setHoverCell(cellEvent)
Parameter change: editPoint(editPoint) -> editPoint(cellEvent)

New Method windowOpen, getColumns, setInfo, getActiveColumns. clearAllCellProperties, getController, setController, prop
New Getter charMap

Deprecated isRowResizable in favor of properties.rowResize
Deprecated isCheckBoxOnlyRowSelections in favor of properties.checkboxOnlyRowSelections
Deprecated showFilterRow in favor of properties.showFilterRow
Deprecated isRowNumberAutosizing in favor of properties.isRowNumberAutosizing
Deprecated updateData in favor of setData without a schema definition
Deprecated getCanvas
Deprecated useHiDPI in favor of properties.useHiDPI
Deprecated isHeaderWrapping
Deprecated isColumnAutosizing

Removed getters and settters for .sorter and .filter in favor get and setController

Hypergrid’s data model filter and sorter properties have been “generacized” (generalized) and are now called “data controllers.”

For example, suppose you have some filter and sorter controllers. The hyper-filter and hyper-sorter plugins are still part of the Hypergrid build (these will be liberated eventually):

<script src="build/add-ons/hyper-filter.js"></script>
<script src="build/add-ons/hyper-sorter.js"></script>

1. Base.notify allows you to throw a console warning, alert or create a Hypergrid error cell

The fin canvas module has been folded into the core of the grid. We will no longer maintain fincanvas 


```javascript
grid.filter = grid.behavior.plugins.hyperfilter.create(schema);
grid.sorter = grid.behavior.plugins.hypersorter;

New way (v1.3)

grid.setController(‘filter’, filter);
grid.setController(‘sorter’, sorter);

Removed dialogOptions, setDialogOptions, openDialog, toggleDialog

EVENT MODULE

1. The event.detail for these events (and others?) is now a cellEvent:
   fin-cell-enter
   Fin-cell-exit

2. renamed: cellEvent.row -> .dataRow

v1.2.1

Hypergrid - 1.2.1

Release date 10/27/2016

Changes regarding advanced data source modules

Introduction. First a quick primer on data source objects. To build a functioning Hypergrid application, you point the Hypergrid rendering engine at a data source. On each grid render, Hypergrid queries the data source by repeatedly calling dataSource.getValue(x, y) for each of the currently visible data cells.
We feel the high-performant rendering (in HTML5) is the primary focus of the grid. We now encapsulate a way for users to provide their own client-side filtering and sorting package (remote is supported as well)!

A “pipeline” of data transformesr can be set up where each one takes as its input the output of the one in front of it. Hypergrid sees the entire pipeline as a single data source object, making calls on the last one in the pipe.

Hypergrid would “run” the pipeline by calling the apply() method which tells the data source object(s) to transform the data. (This may change to a messaging or eventing model in the future.)

What’s changing. Previously, the Hypergrid build included the foundation data source plus a variety of data transformers that provided data transformation services such as sorting, filtering, aggregating, etc. However, going forward we shall only be including the foundation data source (called DataSourceOrigin) in the build. Openfin shall no longer maintain the data transformation objects; nor will they be included in the build. Additionally, these custom dataSources were provided by Hyper Analytics, but having been removed from the core, we will longer be supporting Hyper Analytics as a package.

They will be made available in their current state of development as sample code. The community is welcome to take this sample code, improve upon it (or not), and share the transformers by packaging them as npm modules (for use with browserify) and/or "include files" (.js/.min.js files for inclusion with script tags), etc.

Why we are doing this. The grid is agnostic regarding the data in the data source (and properly so), the Hypergrid development team believes the focus of the project should be on making Hypergrid a lean and fast grid rendering engine and not on data transformations which we have come to view as more as an application layer task.

This release (v1.2.0) removes the filter and sorter data transformer code from the build. Next release we will remove the remaining data source code from the build as well (including the various tree and group view data source components).

Fortunately, the data source objects were all already in separate modules. We removed them from the build and added a simple mechanism for handing them off to the grid: You just pass an array of data source object references to the Hypergrid constructor call as { pipeline: datasourceArray }; or post-instantiation to the grid.setPipeline(datasourceArray) method.

Regarding the filter API. The filter add-on includes the robust filter we’ve been using up to now, known simply as DefaultFilter (an extension of the filter-tree npm module). This is a complex filter and for many grid applications will be overkill. The API interface is extremely simple, consisting of a single required method (test), so it’s very easy to create your own filter.

Datasource access methods. Unlike the data source objects, the various access and support methods were not separate modules put were spread across the various Hypergrid objects. We have teased out all these methods and made them into mix-ins. None of these methods are essential to using the data transformers; they are but one approach. As such they are no longer part of the build.

They are however still available in the repo as plugins. If you still wish to use them, you can find them in the./add-ons folder (in the form of local npm modules) and the build/add-ons folder (as .js and .min.js files). Plugins are simple to install: You just pass an array of plugin reference to the Hypergrid constructor call as { plugins: pluginArray }; or post-instantiation to the grid.installPlugins(pluginArray) method.

Addressing rows and cells

Coordinate systems. Hypergrid works with several coordinate systems:

• The coordinates of the visible grid cells
• The horizontal coordinate of cells inside scrolled columns
• The vertical coordinate of cells inside scrolled rows
• The coordinates of a datum in the abstract data store array

Answering the question, “Which coordinates do I use for which method calls?” has been a trial-and-error affair, and the answer doesn’t always make sense. This is especially vexing when when a method that takes both x and y coordinates expects x to be in one system and y to be in another. Or when a method returns data from the data store but takes grid coordinates, which requires converting the coordinates from one system to another. Hypergrid is focused on execution speed over developer comfort. That said, this constant coordinate conversions also has a CPU time price.

The CellEvent object. With this release we introduce the notion of an intelligent coordinate object called CellEvent which carries with it the essential cell addressing information, including its grid address and dataModel address.

This object also has numerous getters to answer questions such as, “What is this cell’s current value?” “Is this cell currently in the same row as the mouse pointer?” “Is this cell a column header cell?”

Subgrids

Previously, Hypergrid rendered a grid as follows:

1. An optional row of header metadata
2. An optional row of column filter metadata
3. An optional set of top totals rows
4. A scrollable window into an unlimited set of data rows
5. An optional set of bottom totals rows

The new Hypergrid renderer is much simpler and much more flexible. It renders an arbitrary list of subgrids in any order from top to bottom. A subgrid is simply a data model, i.e., a source of data for set of rows to display in the grid.

Subgrids have the following characteristics:

• All subgrids have the same set of columns.
• Each subgrid has its own set of rows.
• The data row (vertical) coordinate is always local to a given subgrid.

The data subgrid (grid.behavior.dataModel) has the following additional characteristics:

• The data subgrid is the only subgrid that scrolls vertically.
• Only a single data subgrid is permitted.
• The data subgrid does not have a type property.

Developers can define their own subgrid classes. Subgrids have the same basic interface as a data model:

• getRowCount()
• getValue(x, y)
• setValue(x, y, value)
• etc.
• In addition, non-data subgrid definitions require a non-falsy type property.

The list of subgrids can be set with the setter:

behavior.subgrids = [ subgrid1, subgrid2, ..., subgridN ];

Each subgrid spec specifies a new or existing data model as follows:

• object type (except when an array) — Assumed to be a reference to an already-instantiated data model. Used as is.
• 'data' special value — The data subgrid (the behavior's already-instantiated data model).
• subgridConstructorRef (see below) — The constructor ref is resolved and called with the new keyword + a reference to the grid as the sole parameter.
• Array object — Accommodates data model constructor arguments. The array should have two or more elements: The first element is a subgridConstructorRef (see below). The constructor ref is resolved and called with the new keyword + a reference to the grid as the first parameter + the remaining elements as additional parameters. (If you don't have remaining elements, there's no point in providing an array here; just provide a simple subgridConstructorRef instead).

The subgridConstructorRef is a jsdoc @typedef defined as one of the following:

• function type — A reference to a data model constructor.
• * string type* — A string containing the name of a registered data model constructor

The subgrid array can be referenced with the getter:

var mySubgridsArray = behavior.subgrids;

You can dereference (look up) an individual subgrid within the list in several different ways:

• by index (of course): behavior.subgrids[n]
• by key (name): behavior.subgrids.myHeaderModel — Useful for named subgrids (the name property is optional).
• by key (type): behavior.subgrids.header — All subgrids (with the exception of the data subgrid) are required to have a non-falsy type property.

Although the data subgrid is defined as having no type property, the special lookup key 'data' can always be used to dereference the data subgrid (behavior.subgrids.data).

Note that name keys have priority over type keys in case they clash.

The Hypergrid Launch Sequence

To initialize a Hypergrid, call the constructor:

var grid = new Hypergrid;

This will create a new grid with a standard height of 500 pixels in a <div> element with a default name of “hypergrid”.

Alternatively, you can specify a div with a CSS style selector:

var grid = new Hypergrid(‘div#mydiv’);

or

var grid = new Hypergrid({ container: ‘div#mydiv’ });

The grid cannot be rendered however until you give it some data like this:

grid.setData([ { Age: 25 }, { Age: 24 }, { Age: 32 } ]);

You can add data transformers with grid.setPipeline. The current default is empty so if you want sorting, filtering, etc., you will need to add these.

You can add plug-ins with grid.installPlugins.

You can specify subgrids by assigning an array to grid.behavior.subgrids. Currently the default subgrids list is [header, filter, top summary, data, bottom summary]. However, note that you will only see a header row and the data rows because:

• Filter subgrid is hidden by default. To se...

v1.0.10

• Fixed: Bug introduced by 1.0.9 where grids using columnAutosizing continuously re-rendered causing 100% CPU usage
• Added missing row access add-on demo (row-by-id.html)