Based on lots of feedback we received over the years, on the EGL Cafe, and in personal contacts, we started with our well known, plain old Rich UI Grid, and added the following functions as built-in features:
- Paginatiion. The Grid now has a new parameter called pageSize and if more rows are available than fit in the grid, pagination buttons are automatically added. The pagination buttons can be fully styled.
- Scrollbars. When too many rows are available to show in the current page size, you can choose to show a scrollbar, rather than the above mentioned pagination buttons. Scrollbars are often-requested, but they can have a negative performance impact, and navigation may be cumbersome for end-users. Pagination buttons are recommended over scrollbars for most business applications.
- Selection. One or more rows can be selected by clicking on a row. Pressing the Ctrl or Shift key at the same time selects multiple rows. And the kicker is that the current selection is maintained in combination with both Pagination or Sorting! Again, easily customizable CSS is used to control how the selection is represented.
- Resizable columns. Columns can be resized. The latest value is stored in a cookie, and will be reused when the page is revisited. A unique grid id is recommended to resolve conflicts in applications that use multiple Grids.
- Data Provider/Model-based data. Rather than providing all data to a grid, data can be provided page-by-page, using a data cache provider attached to the Grid. Such a cache provider would make a service call, retrieve the next page, and return it to the grid when so requested. We call it a cache provider, as the provider can have numerous strategies for obtaining the data. It may fetch data from HTML5 browser-side storage, fetch buffers that are multiple pages, use special data compression, or any combination of the above. With a data cache provider, grid can truly scale to show millions of rows, while only retrieving pages on demand when they're needed.
- Ultra-High Performance. A lot of engineering time has been spent into optimizing the Grid (especially for Internet Explorer), where we obtained improvements of up to 20X faster rendering with the new Grid.
- Formatters. We added formatters to the Grid columns for often used formatting rules that should be applied to an entire column. Examples are adding a dollar sign, coloring a cell based on the value being rendered, etc. Formatters operate on text strings, and not on actual widgets, for performance reasons.
- Much improved default CSS styling. See examples below.
- Alignment. We added alignment to GridColumns, both for the header and the grid cells. This allows you to customize both cell and header alignments per column.
- API Compatibility. Your old grids should work just fine with this new Grid. We have deprecated some Grid behaviors, as they are now done using formatters. However, any pre-existing Grid should work as before.
- Synthetic columns. Allow the user to create a column with a "dummy " name (i.e name that doesn't exist in the data record) and then create a formatter to compute its value based on other values in the record.
- Allow column resizing by resizing a column with the mouse and column sorting using drag-and-drop. State is saved in a cookie and reloaded at next run. Grid has parameter ("enableResizing") to influence this behavior. Each column has its own parameter to override the Grid's parameter.
- The grid renders the table, even if data hasn't been specified. It shows an empty table.
The outstanding wish list of cool features to add to the grid include (but are not limited to):
- Grid should provide an API to access column order and sort information (so the developer can save in a cookie). Grid now saves this stuff automatically in a cookie, but what if the developer doesn't want this information to get saved (i.e. they want the table restored to the default every time)? We can add APIs to get layout information (as a set of records), then the developer could choose to save as a cookie.
- Filtering - allow developer to programmatically control whether a record is rendered in the table or not. delegate filter(record Any in) returns (boolean). It is not certain how this would work with the Grid's data cache.
- Context menu support (allow user to right-click on a row and perform some action)
- Your feature request goes here...
Below are a few samples that show the new Grid features.
The first sample shows a Grid with 4 columns, each can be clicked to sort the grid by that column. Each column is resizable (we made the Age column wider), and it shows a scrollbar to let users scroll to rows further down in the data set:
The second sample shows 2 grids, where one uses pagination, selection, and sorting. The second grid has those features turned off, and it's currently shown page is synchronized with the first grid. Both grids show the same dataset:
The third sample shows a grid using built-in and custom column formatters. Selection is shown using a highlight (colored salmon using CSS in this sample) and using checkboxes:
In the fourth sample, we change the pagination to not use buttons, but use a scrollbar instead:
In the final sample, we decide to hide the checkboxes:
Attached, please find 2 projects. One is an experimental version of our RUI widgets projects with the new Grid included. To use the new Grid, edit your project's EGL Build Path, and replace the reference to the old rui_1.0.2 project to this new experimental one. The second project contains a few samples that demonstrate the new APIS.
As I said earlier, this is still work in progress. Known issues:
- CacheDemo needs more work and use a real database. It currently does not implement sorting, and column sorting now work on incomplete data
Please look at the samples, verify the new API, and make sure it works on your code. Then, let us know in a comment if you have any other feature requests so we can continue to make this Grid widget the best possible one.
- new_grid_march29.zip (EGL CE archive with 2 projects)