Extend DataTableLookUp with optional argument: default row
What changed
-
DataTableLookUpis extended with an optional argumentdefaultRow. This argument allows to specify a default row for the lookup, so in case the looked for value was not found in the searched column, the default row will be returned. Unless the column contains anemptyvalue, then the row of theemptyis returned. (If the look up doesn't specify a column for the search, the tables default column is used) - Tests for
DataTableLookUpandDataTableare cleaned up and improved
Limitations
- Resolved with 45b6c56:
When theDataTableLookUpdoesn't specify a default column, but uses the tables default column and is about to add thedefaultRowargument, the code completion menu suggests the,two times.
Currently it's too hard to resolve this:
- Either remove the menu item by removing the IDotTarget_TransformationMenu. This has an impact on every
IDotTarget - Add a transformation menu to the
DataTableLookUp, but then other invalid entries are proposed - This can even be influenced by MPS changes, when calculations are changed on how the entries for the menu are accumulated
- Either remove the menu item by removing the IDotTarget_TransformationMenu. This has an impact on every
Todos
- [x] Clarify whether the changed behavior regarding the default is okay (@wsafonov, @mgronover, @AlexeiQ )
- [x] Clarify the
#alias#versus constant-cell question - [x] Add release comment
- [x] Remove Draft, add Reviewers and
Prio-label
Extended DataTableLookUp with an optional argument to specify a default row, so if no result is found and the column doesn't contain an empty value, the default row is returned.
The lastest changes look good and are working (45b6c56 + 02f1a08). This also resolves the initial limitation. Great Job!
Question: Do we have an convention when to use #alias#-cell and when to use a simple constant-cell?
In this case the lookUpBy and default cells are #alias#, which means, they are editable, but don't delete the node. Regular constant-cells are not editable and can delete the complete node, when the curser is on that cell. lookUpBy is an iDotTarget like oneOf or toList and those use the constant-cell instead of an alias. Thus we have different behavior and I'm wondering if we have some convention when to use what to have a consistent behavior.
The default-part of the DataTableLookUp cannot be deleted, when the cursor is placed on the default keyword. Deleting from the = and from eg. first position of the value works fine. As Discussed, this should be fixed as well.
The
default-part of theDataTableLookUpcannot be deleted, when the cursor is placed on thedefaultkeyword. Deleting from the=and from eg. first position of the value works fine. As Discussed, this should be fixed as well.
This is fixed now. But when the caret is placed right behind val1 (s. below), pressing DEL has no effect.
The user has to move the caret to the right side of the , to have the expected delete operation (both DEL and Backspace are working here).
According to (https://github.com/IETS3/iets3.opensource/pull/624#issuecomment-1382066670) the #alias# editor field was exchanged by a constant to make the editor action workable (#alias# with read-only style does not call the required actions) .
@AlexeiQ, @mgronover in case we need this please change the target branch to at least maintenance/mps20213