Expression Language Ideas

Branching from a previous post

Here are a few ideas:

  1. Documentation:
  • I’m as guilty as the next guy, but I don’t know how we train developers to regularly review the documentation. Example: Just yesterday, a co-worker asked me if SnapLogic dates/times could be compared in expressions, so I gave my best educated answer and then thought to look it up and point them to the documentation Comparing Dates.
    (this point may not be helpful, but provided as an example)
  • The documentation’s “This is similar to the JavaScript {method xxx}” phrases should be replaced with full/complete documentation relevant to the expression language. Or at least point out the differences between the e-lang and JavaScript. We’ve been impacted and had to adapt to some behavioral differences between the e-lang and JavaScript methods.
  • All new or modified expression language methods/behaviors should be included in the platform release notes and/or an available change log. I’ve missed out on a lot of new e-lang additions which would have been beneficial to me much sooner. As well, it’s been a long while, but we’ve been impacted by one or two language syntax fixes that were working the way we were implementing and then failed after the release.
  1. Training
  • Advanced tutorials/examples (i.e. YouTube) for Expression Language and Expression Library would be great. Our team doesn’t utilize the Expression Library feature near enough, but it’s an extremely useful feature. Also, the arrow functions (another beneficial feature) are a new concept for some inexperienced developers.
  1. UI / UX
  • A “suggest” feature (with documentation) would be cool when writing expressions in a mapper or other snap. After I type out a string or an object representing a string, It would be handy to see all the string methods pop up in a suggest list (maybe after a pause and possibly provide a link to the string documentation).
2 Likes

Twenty years as a tech writer and I still don’t know a foolproof method to solving this problem. :slight_smile:

I agree, we need more on the expression language. I’m expecting some tutorials to come to our Knowledgebase soon.

1 Like

We’re trying to partially address this through dynamic validation and encouraging folks to just try things out to see the results. For example, with the 4.13 release, function parameter names are now included in the error messages for an incomplete expression:

As well as the intermediate results (note that the cursor is next to the close parentheses of the method call, so it’s parameters are displayed as the intermediate result):

So, you can just start typing and get immediate feedback. We can look into extending this functionality to include links to the full documentation. Taking your example of comparing dates, you could write something like:

$birthday < Date.parse('2010-01-01')

Then, when the cursor was next to the less-than sign, we could display the result for that operation and include a link to the “Comparing Dates” documentation to explain what was going on. Or, if the cursor was over the “parse()” function, we could link to the documentation for that (as you suggest below).

In general, we want the e-lang to follow JavaScript as closely as possible to avoid this type of confusion. If you can remember, can you list some of the differences that are the biggest thorns in your side so that we can address them.

To give you a peek behind the curtain, we’re trying to improve our prerelease testing to compile and execute the expressions in pipelines with the new and old versions of the e-lang implementation to see if there are any differences. This testing should reduce the chances of this type of breakage happening in the future.

Dynamic Validation has some basic support for showing the possible properties/methods, if you haven’t noticed. For example, if you write a string literal followed by a dot and then pause to allow DV to run, you’ll see something like the following:

During dynamic validation, the expression is compiled differently to allow for incomplete expressions. The expression is then executed as much as possible before an error is raised. This allows us to work with the actual input values so we can give more informative error messages, like listing the available methods.

Thanks for the writeup!