iets3.opensource icon indicating copy to clipboard operation
iets3.opensource copied to clipboard

Extend DataTableLookUp with optional argument: default row

Open AlexeiQ opened this issue 3 years ago • 6 comments

What changed

  • DataTableLookUp is extended with an optional argument defaultRow. 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 an empty value, then the row of the empty is returned. (If the look up doesn't specify a column for the search, the tables default column is used)
  • Tests for DataTableLookUp and DataTable are cleaned up and improved

Limitations

  • Resolved with 45b6c56:
    When the DataTableLookUp doesn't specify a default column, but uses the tables default column and is about to add the defaultRow argument, the code completion menu suggests the , two times. image 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

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

AlexeiQ avatar Dec 02 '22 21:12 AlexeiQ

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.

AlexeiQ avatar Dec 05 '22 17:12 AlexeiQ

The lastest changes look good and are working (45b6c56 + 02f1a08). This also resolves the initial limitation. Great Job!

AlexeiQ avatar Jan 13 '23 15:01 AlexeiQ

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.

AlexeiQ avatar Jan 13 '23 16:01 AlexeiQ

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.

AlexeiQ avatar Jan 20 '23 18:01 AlexeiQ

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.

This is fixed now. But when the caret is placed right behind val1 (s. below), pressing DEL has no effect. image 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) .

mgronover avatar Jan 23 '23 13:01 mgronover

@AlexeiQ, @mgronover in case we need this please change the target branch to at least maintenance/mps20213

arimer avatar May 14 '24 14:05 arimer