TableModel: Difference between revisions
Jump to navigation
Jump to search
(Created page with "TableModel provides a QAbstractTableModel that can be used from QML with TableView. == Requirements == == Approach #1 "rows" == Current (unfinished) state as of writing can...") |
mNo edit summary |
||
| Line 23: | Line 23: | ||
How the actual source JS data is stored and formatted is up to the user, | How the actual source JS data is stored and formatted is up to the user, | ||
* rowCount and columnCount would then have to always be specified so that we know how many there are. | * rowCount and columnCount would then have to always be specified so that we know how many there are. | ||
* "roles" allows the user to use their custom roles without us having parsed the rows data | * "roles" allows the user to use their custom roles without us having parsed the rows data (currently we parse it up front using an expected format so that we know which roles are available): | ||
roles: [ | roles: [ | ||
| Line 36: | Line 35: | ||
] | ] | ||
* Then we call roleDataProvider() unconditionally each time data() is called for a "new" index, | * Then we call roleDataProvider() unconditionally each time data() is called for a "new" index, and store that in our own well-formatted map/hash, so we don't need to call roleDataProvider() again for that index. | ||
* As appendRow(), moveRow(), etc. would no longer take the row as an argument, they would need to | * As appendRow(), moveRow(), etc. would no longer take the row as an argument, they would need to | ||
be replaced with beginAppendRow()/endAppendRow(), etc. | be replaced with beginAppendRow()/endAppendRow(), etc. | ||
Revision as of 12:36, 27 February 2019
TableModel provides a QAbstractTableModel that can be used from QML with TableView.
Requirements
Approach #1 "rows"
Current (unfinished) state as of writing can be seen here: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/types/qqmltablemodel.cpp?h=dev&id=b4ee855eb10cf9bfa44ce8e5de8f9ee6c5917764
In addition, there are some follow-up patches:
- https://codereview.qt-project.org/#/c/253255/
- https://codereview.qt-project.org/#/c/253234/
- https://codereview.qt-project.org/#/c/253509/
Approach #2: No "rows"
- We know we can't expect one data format/structure for rows; need to be flexible.
- We know we want settable rowCount + columnCount for prototyping and allowing use cases such as e.g. spreadsheets.
- roleDataLookPolicy (https://codereview.qt-project.org/#/c/253509/) is making things quite complex
So:
- Remove "rows" altogether.
How the actual source JS data is stored and formatted is up to the user,
- rowCount and columnCount would then have to always be specified so that we know how many there are.
- "roles" allows the user to use their custom roles without us having parsed the rows data (currently we parse it up front using an expected format so that we know which roles are available):
roles: [
["driverId"],
["code"],
["url"],
["givenName"],
["familyName"],
["dateOfBirth"],
["nationality"]
]
- Then we call roleDataProvider() unconditionally each time data() is called for a "new" index, and store that in our own well-formatted map/hash, so we don't need to call roleDataProvider() again for that index.
- As appendRow(), moveRow(), etc. would no longer take the row as an argument, they would need to
be replaced with beginAppendRow()/endAppendRow(), etc.