In this engineer blog, I’ll introduce what I’ve been learning recently. This time, I’ll explain automatic column generation in OutSystems Data Grid.
- OutSystems Data Grid is a spreadsheet-like grid that can be displayed and interacted with within an OutSystems application.
- This article assumes prior knowledge of OutSystems Data Grid.
Problem Statement
For example, let’s say we have a grid like the one below.
The usual way to create it would be as follows.
- Set the data to be displayed into a Structure that matches the grid layout, convert it into a list, transform it into JSON using ArrangeData, and set the resulting JSON as the grid’s data.
- Place a column widget on the grid for each column to be displayed, and configure each header, column width, display conditions, and so on.
For a grid with six columns like the one above, it’s not too difficult. However, if the number of columns to display is variable, creating it becomes more challenging.
You need to determine the maximum number of columns to display, then prepare the Structure from step 1 and the column widgets from step 2 to match that maximum number. Additionally, you must control the visibility of each column based on how many you actually want to display. As a result, all the columns up to the maximum exist, but only the desired number of columns are visible.
Especially for step 2, if the grid’s configuration is even slightly complex—such as having merged headers with dynamic labels—the amount of work required increases significantly.
If the maximum number is around 100, it might take some time, but it’s still manageable. However, I once faced a case where the maximum number reached nearly 1,500. At that time, I looked into whether it was possible to generate the grid columns using JavaScript.
As a result of the automatic generation, step 1 of the usual method still needs to be done as is, but step 2 becomes much simpler.
Prerequisites
In a grid like the one below, the columns outlined in red are the target for automatic generation. (The left three columns are placed as usual. The auto-generated columns are on the right.)
The cells in the auto-generated columns will be set to read-only. The column order in the grid will be fixed and cannot be changed.
The data to be displayed in the grid has already been retrieved and is set to the grid as described in step ① above.
The header labels (such as ‘グループ1’, ‘データX’, ‘名名名’, etc.) are dynamic and have already been retrieved in a format that can be passed into JavaScript. (In the sample JavaScript code, these input parts will be shown in bold.)
In the implementation JavaScript, we use a variable called dataGrid. You can obtain dataGrid as shown below. (Let gridId be the ID of the configured grid.)
var dataGrid = OutSystems.GridAPI.GridManager.GetGridById('gridId').provider;
Preliminary Research
From the link below, I found that it’s possible to push columns into dataGrid.columns.
Upon further investigation of dataGrid, I found that in addition to columns, there is also columnGroups. I thought that by pushing to columnGroups, it might be possible to create grouped, merged header columns.
Implementation Flow
In the ‘On After Fetch’ action after retrieving the data, implement it as follows.
The first column of ‘グループ1’
// Create the element to push
var newColGroup = new wijmo.grid.ColumnGroup (
{header: 'グループ1', align: 'left', columns: [
{header: 'データX', align: 'left', columns: [
{header: '名', binding: 'Data1', width: 100, align: 'left', isReadOnly: true}
]}
]}
)// Push newColGroup into columnGroups
dataGrid.columnGroups.push(newColGroup);
The second column of ‘グループ1’
// Create the element to push
var newColGroup = new wijmo.grid.ColumnGroup (
{header: 'データ1', align: 'left', columns: [
{header: '名名', binding: 'Data2', width: 100, align: 'left', isReadOnly: true}
]}
)
// Push newColGroup into the columns of the target columnGroup
// columnGroups[3] refers to the created "Group 1", which is at index 3 in columnGroups
dataGrid.columnGroups[3].columns.push(newColGroup);
the ‘グループ2’ column
// Create the element to push
var newColGroup = new wijmo.grid.ColumnGroup (
{header: 'グループ2', align: 'left', columns: [
{header: 'データV', align: 'left', columns: [
{header: '名名名', binding: 'Data3', width: 100, align: 'left', isReadOnly: true}
]}
]}
)
// Push newColGroup to columnGroups
dataGrid.columnGroups.push(newColGroup);
As shown above, grouped columns with merged headers are created one by one.
By adjusting the structure of newColGroup and the target of the push accordingly, it should be possible to create column groups with different structures.
additional support
When automatically generating columns, the following two points must be taken into consideration.
- The variable
dataGridrepresents the grid obtained as a JavaScript object. At the time the ‘On After Fetch’ action is executed after data retrieval, the grid must already exist. One way to handle this is to set the data retrieval action’s timing to ‘Only on Demand’ and execute it in the ‘OnReady’ action.
- If the grid contains columns with editable cells, a post-edit check is performed on the entire row to determine whether any cells were edited. However, if this check tries to access the automatically generated columns, it will result in an error. (In the grid used as an example in this article, the ‘Settings’ column is editable.)
To handle this, adjust the edit check in the grid’s ‘OnInitialize’ action using JavaScript as shown below.
// Regular cell edit check
var originalCheck = OutSystems.GridAPI.GridManager.GetGridById('gridId').features.dirtyMark._isDirtyCell;
// Adjust the check
// Immediately treat cells in auto-generated columns as unedited
// Since columns with index 3 and above are auto-generated, control with "columnIndex > 2"
var newCheck = function (rowIndex, columnIndex) {
if (columnIndex > 2) {
return false;
} else {
var checkResult = originalCheck.call(this, rowIndex, columnIndex);
return checkResult;
}
}
// Apply the adjusted check to the grid
OutSystems.GridAPI.GridManager.GetGridById('gridId').features.dirtyMark._isDirtyCell = newCheck;Stay tuned for the next developer blog.
