Binding all RowColumnDefinitions in an itemArray

GoJS
1

Hello, I am using this example of resizing rows and columns in a Table - Resizing Rows and Columns in a Table Panel

In the example, the column width binding for each RowColumnDefinition is hard-coded with the index of each column like this:

$(go.RowColumnDefinition, makeWidthBinding(0)),
$(go.RowColumnDefinition, makeWidthBinding(1)),
$(go.RowColumnDefinition, makeWidthBinding(2)),

This example does not have resizing bindings for the height values, but if I wanted to make such height bindings for the RowColumnDefinition of each row in “fields” is it possible to assign these bindings dynamically based on the itemArray instead of hard-coding each binding?

I have tried something like this but the RowColumnDefinition.bind(…) does not seem to be working

        new go.Binding('itemArray', 'fields', (fields, table) => {
          fields.forEach((field, index) => {
            const rowDefinition = table.getRowDefinition(index);
            rowDefinition.bind(makeHeightBinding(index));
          });
          return fields;
        }),
2

Yes, at present there is no support for binding RowColumnDefinition properties in “TableRow” or “TableColumn” Panels.

One solution is to customize the RowResizingTool.resize or ColumnResizingTool.resize method so that in addition to modifying the RowColumnDefinition.height or RowColumnDefinition.width, respectively, it also modified some data property. That would replace the TwoWay functionality of a data binding.

Additionally you would have to implement functionality to read those data properties to update the height or width of the corresponding RowColumnDefinition. That would replace the normal data-to-target binding behavior.

Maybe we should improve the sample to demonstrate that.

3

Thanks, walter. The solution to customize the Column and Row resizing extensions is a good workaround for setting the new values to the data.

4

Yes, the purpose of TwoWay binding is that it is a convenient way to remove app-specific knowledge about data from the tools and commands. Normally that knowledge should only be in the templates. That’s why all of the predefined tools and commands can work without any knowledge about the data.

It’s unfortunate that we still have to do some method overrides, but we are trying to reduce that. However, there’s no way to avoid it – it’s amazing what some people want to do.