Specialist Parameters
There are one or two parameter types that fall outside of the general text/numeric/choice types, and yet are worth taking a close look at.
Scripted Parameters
Scripted parameters go one step further than an embedded parameter.
Whereas an embedded parameter allows simple construction of a new value by concatenation, a scripted parameter allows a full Python or Tcl script to be used to construct a value.
For example, here is the definition for a Tcl scripted parameter that, again, concatenates a filename from the user with a set path from the author.
However, in this case, the script is used to test whether the workspace is being run on a Windows or Linux system, so it can set the output path accordingly:
set realname '' if {[string match 'C:*' $FME_MacroValues(FME_HOME)]} { set realname 'C:\Output\'+$FME_MacroValues(UserFileName) } else { set realname '/Output/'++$FME_MacroValues(UserFileName) } return realname
Note that the script must include a return statement, to return a value to the parameter.
All Scripted Parameters are private by default, and can never be published, as it would be absurd for a user to be prompted to enter Python code when a workspace runs!
Ms. Analyst says… |
Use the ‘print’ command (in Python) or ‘puts’ command (in TCL) to write from the script to the FME log file. |
Attribute Name Parameter
Sometimes an FME parameter is designed to accept either a fixed value or the value of an attribute. We call these parameters _OR_ATTR parameters, because they allow a value OR an attribute.
For example, this LabelPointReplacer allows the label to come from a fixed value, or an attribute:
When the end-user is required to set this FME parameter, then it’s simply a case of turning it into a linked user parameter. When the workspace is run, FME will scan the workspace to find what attributes are available to that transformer, and allow the user to select one or enter a fixed value.
However!
Perhaps the workspace author does not want the user to be able to enter a fixed value. They want the user to only be able to select an attribute.
In this scenario we need to create a user parameter with a special type called Attribute Name:
Now when the workspace is run, the user is permitted to select an attribute, and ONLY an attribute:
However (again)!
There is a catch to this operation. The user parameter – as the type suggests – is simply returning an attribute name; it does not return the attribute value.
If the workspace is run in this state then the LabelPointReplacer is supplied with the attribute name (not value) and uses it as the label, like so:
What the author must do is open the parameters dialog and change the parameter (either directly in the FME parameter, or via the Text Editor window) to be: @Value($(UserAttrSelection))
The @Value() function replaces the name of the attribute with its actual value:
Now when the workspace is run the output will be correct: