You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the new feature being added
Our DataModel should be easily adaptable to cases where we want to have column and row header sizes of arbitrary size.
How will this feature improve this extension
There are cases where it makes sense to allow for multiple row headers and column headers. One case is where you want to have a column header filled with a standardized entry (e.g. letters as in Google Sheets and Microsoft Excel) as well as column headers with names that describe the data in the column. The data grid was designed with these possibilities in mind. it supports an arbitrary size for the row headers and the column headers. there is no reason that our data model shouldn't be as flexible as our UI.
Describe alternatives you've considered
The primary alternative would be to stick with a more rigid restriction for the number of column headers and row headers. This may be able to cover most use cases, but it seems beneficial to at least make room for the greater flexibility even if it is rarely used.
Additional context
One thing worth noting is that making this change most likely requires extending the DSVModel or submitting a pull request to JupyterLab to make this module more flexible
The text was updated successfully, but these errors were encountered:
Describe the new feature being added
Our
DataModel
should be easily adaptable to cases where we want to have column and row header sizes of arbitrary size.How will this feature improve this extension
There are cases where it makes sense to allow for multiple row headers and column headers. One case is where you want to have a column header filled with a standardized entry (e.g. letters as in Google Sheets and Microsoft Excel) as well as column headers with names that describe the data in the column. The data grid was designed with these possibilities in mind. it supports an arbitrary size for the row headers and the column headers. there is no reason that our data model shouldn't be as flexible as our UI.
Describe alternatives you've considered
The primary alternative would be to stick with a more rigid restriction for the number of column headers and row headers. This may be able to cover most use cases, but it seems beneficial to at least make room for the greater flexibility even if it is rarely used.
Additional context
One thing worth noting is that making this change most likely requires extending the
DSVModel
or submitting a pull request to JupyterLab to make this module more flexibleThe text was updated successfully, but these errors were encountered: