Representing FEEL Expressions in Table Format - Gnorion/BizVR GitHub Wiki

I think we can improve the way we map expressions into BVR.

Currently:

1. the variables are identified and added as condition names
2. the expression itself (no matter how large) becomes a single action

Proposed

1. continue to show the variables as conditions
2. decompose the expression into its component lines and show separately in the table layout Sometimes the expression will only be a single line, but many times it will consist of multiple lines (separated by commas) each representing a distinct step in the expression (pretty much like lines of code)

Here's a single expression in DMN which is really 8 distinct steps (separated by commas)

In BVR it would look like currently:

which is really not manageable even with the little popup window

I'm proposing we represent it like this:

or maybe like this (if we can make the rule column bigger)

Then on the BVR diagram you could see either this (with just the output names)

or this (including the expressions)(depending on how you entered the rule)

Both views have their advantages and disadvantages

Essentially each contextEntry in the FEEL parse tree would become a separate line in the table actions:

They would still be FEEL expressions at this point (since we are still DMN/BVR) but further down the road when the user wants to move to full BVR he will already have the decomposed FEEL expressions as a starting point. In some cases (where the syntax matches ours) there would be nothing more to do. In other cases they might need to modify the syntax a bit. But the closer BVR syntax is to FEEL syntax the more compatible the two will be. The single DMN FEEL expression could be reconstructed from the table form when exporting as DMN as needed.

Here's the scheduling example (comparing BVR and FEEL) which has more complex conditions (collection bindings) https://github.com/Gnorion/BizVR/wiki/Mapping-of-Tables-and-Expressions-(SCH015)