Skip to main content
New

Support defining (scripted) parameters as conditionnal values

Related products:FME Form
  • September 29, 2025
  • 1 reply
  • 19 views

vlroyrenn
Enthusiast
Forum|alt.badge.img+14

Most of my workflows have a lot of scripted parameters with various amounts of boilerplate code just to deal with handling defaults and fallbacks.

The parameters with uppercase names are all scripted

This is all just to handle both cases in the simple scenario where “Recent bound (current time if empty)” is, as the name implies, optionnal and defaulting to the moment where the script was launched if left empty.
 

If I was dealing with attributes, it would literally just be this:

 

I believe we should have a type of scripted parameter that allows using the same facilities and functions for parameters as we do with attributes, especially conditionnal values. This would make using default values and dropdown-presets, as well as format uniformization a lot easier to encode in the parameters without having to include (which often means duplicate) that logic in the transformers, or having to use Python scripts (which do not generate log files if they raise any errors) for simple operations like this.

1 reply

vlroyrenn
Enthusiast
Forum|alt.badge.img+14
  • Author
  • Enthusiast
  • September 29, 2025

If that DATETIME_HIGH_BOUND parameter script looks harmless, you should know that it’s ont of the most common causes of crashes for that flow. Python scripted parameters are not guarenteed to run with the same Python version as the workbench, and slight changes between Python versions or environments (namely ZoneInfo data availability and logging.basicConfig parameters) can raise unexpected exceptions that kill the flow run before any logs are created.

I now try to avoid using Python scripted parameters unless they’re less than 10 lines long, and even then I would look for alternatives.They are very frustrating to work with, and I say that as a trained programmer.