Tester 2019: Keep the old composite test

At our FMEWT19 Espoo event there was also customer feedback hoping to have the old way available.

Old one was definitely easier for complex composite tests. Geolassi has a good idea how to fix this situation.

I vote for this idea. The former method was simpler and easier to compose.

I also prefer possibility to see a clear SQL statement when using composite test.

I also prefer possibility to see a clear SQL statement when doing composite test.

At the very least it should be possible to have an ‘echo’ of the full test shown.

w

Is a lot harder to parse if you have the parentheses in the correct place than seeing it like

Also the previous version would allow you to repeat elements (1 and 2) or ( 3 and (1 or 2)).

Thanks for your feedback. In FME 2019.1, we are planning to add a preview which should help with the usability of the composite expressions. With this addition, you can easily visualize the composite expression and identify syntax errors. The text wraps on multiple lines if the composite expression is long. If there is a syntax error, the corresponding cell in the table will be highlighted red.

Here is a screen capture of a 2019.1 interface of a simple composite statement containing an error. We would be interested in your feedback on this improvement to understand if it sufficiently addresses your concerns.

We considered re-adding direct editing but felt the biggest regression in the new design was the inability to view, rather than the entry of composite expression. The line edit input mechanism of the previous version had some limitations: no syntax highlighting, single line visible, and users could add numbers that did not have tests which would cause runtime failures.

Hi folks,

Thanks for your feedback. In FME 2019.1, our developers are planning to add a preview which should help with the usability of the composite expressions. With this addition, you can easily visualize the composite expression and identify syntax errors. The text wraps on multiple lines if the composite expression is long. If there is a syntax error, the corresponding cell in the table will be highlighted red.

Here is a screen capture of a 2019.1 interface of a simple composite statement containing an error. We would be interested in your feedback on this improvement to understand if it sufficiently addresses your concerns.

'

Notice there is no direct composite expression edit. We considered re-adding this but felt the biggest regression in the new design was the inability to view the composite expression, so wanted to fix that first.

Note that the editing mechanism of the previous version has some limitations: no syntax highlighting, single line visible, and users could add numbers that did not have tests (which would cause runtime failures). So if it were to be added back then you'd lose the validation functionality that you have when editing the logic column of the test clauses.

So let us know what you think!

Mark (on behalf of Shelley and the rest of our Desktop development team)

That would definitely help. I spend over 10 minutes this afternoon trying to figure out where the problem was in a 16 element composite test.

The proposed FME 2019.1 way to add a preview and highlight errors is already much better, but why not have e.g. "advanced mode" where you and write/copy_paste the full expresion into the preview window and then generate from that the above one. If no errors then fine, if errors then showing it. E.g. to add to the preview window edit possibility and generate_from_preview-button.

I agree with Hannu-Pekka, the issue with the new ui and preview will still be there: it's slower to define the composite test clause for advanced users. If the old composite test doesn't get back, I guess I just have to use 2018.1 Tester. I think many users will agree, who have used the old Tester composite tests for many years.

A button for an advanced editor would be a good idea.

Hi @mark2atsafe, why not make the 'preview' editable but still highlight errors? Similar to a python IDE such as pyscripter or IDLE.

I think it's partly because if you're typing directly into a text field, then live parsing becomes more of a hindrance than a help. Like if I type a ( character, then it would immediately highlight red, because there's not (yet) a matching ) character. That sort of thing always bugs me. So it would be like it was before, with a plain text field.

The contents of the logic column would be updated to match and parsed for errors, but not until you click apply or tab out of the text field. So I think it could have validation, just not "live" or "as you type" validation.

The more I use the new interface, the less I like it. It heavily brings to mind the bad old days of the StringConcatenator basic mode, which was incredibly cumbersome to use vs the advanced mode. Could we not likewise have a basic and advanced mode for the tester?

Though one improvement I would like to see in the old composite test, is if you move a component, the numbers in the composite test should auto update.

I see what you mean, but it's pretty common in regex editors or as I mentioned python IDEs and I for one don't mind. Possibly an optional feature then.

In my opinion, the main downside of the previous implementation (before 2019) was that interpreting the complex composite expressions was very difficult due to the visualization with the row numbers instead of the actual values behind it. In that sense, the visualization of the composite expression would only be helpful to me if it does show the actual values instead of the row numbers.

I think two ideas could be helpful here:

1. View Mode

In the view mode as showed above, implement visialization of the logic behind the row numbers.

( 1 OR 2 OR 3

but:

( asf = af OR asf = asf OR as = asf

In the example above only text values are used, but even better would be to visualize in case of attributes, the attribute names. If we assume the left values are attribute names, e.g.:

( @Value(asf) = af OR @Value(asf) = asf OR @Value(as) = asf

2. Edit mode

Make an advanced text editor (as in e.g. StringConcatenator) to be able to construct the expressions yourself. In that way you can construct an expression like below (and above) by typing and/or selecting values from the menu on the left.

( @Value(asf) = af OR @Value(asf) = asf OR @Value(as) = asf

I preferred the old tester interface, I find it confusing that the comparison mode is hidden an the bottom of the window and have to explicitly set it to use Case Insensitive for one test. It would work better I think and be more obvious to users if was returned to the right hand side and initially set on Automatic mode. I had a workspace that had Case Insensitive turned which I lost when I installed 2019 and it went to Automatic mode.

Also putting lone brackets on lines and having to find the right combination of brackets with AND/NOT etc is really clunky and took me a long time to figure out. It would be easier if you could give each line a name or number that would move with the line if moved up or down and then go back to the original syntax typing for ((A and B) or C).

There is always the attriubte creator to do i in.

Use math and logic operators. Downside the sheer number if @Value() strings.

I also prefer the olde version.

Because i don't need to use al tests in the tester or use tests multiple time in different composite rules.

The composite test can be drven by attribute.Though the tester also did not have a aritmic editor on the left hand side. Which drove me to use the attributecreator more. The vertical reading is lame.