This wish/idea applies to parameters with aliases. I’m finding cases where I need to make a decision somewhere in the workspace based on the Display Name of a parameter, not the Value (for parameters with aliases such as the following):
However only the "Value" is visible in the workspace. The only way I have found to get around this is to avoid using this type of parameter and only use the “Choice” version, then use an AttributeMapper in the workspace to map the needed value to a new attribute. It would be great if the "Display Name" was also accessible in the workspace to avoid having to use the AttributeMapper workaround.
I'm not following why you couldn't just test of the value, if it's coming from a choice with alias parameter.
However, a workaround that avoids needing an attributeMapper is to have your value portion contain a pipe separated list, of both the real value, and the display name. Then in the workspace use an attributeSplitter to split them into the component parts. It does mean a few more transformers, but you don't have to maintain your DisplayName Value mapping in two different locations.Hi @jdh, so the reason is that the value in the example above is "non-memorable". For example it is a cryptic ID or token. Or the values change over time and are updated, but the Display Name is static and definitely more memorable. So the workspace would not need to be updated when the value changes. Hope that explains the use-case. As to your suggestion, the issue with that is that this workspace also runs on FME Server so I want the drop-down functionality that the parameter with alias offers: the user selects from the more user-friendly and readable list under Display Name and the value is transparently assigned for the workspace to do it's thing. My wish is to also make Display Name available for the workspace to utilize in its logic. Thanks.
My proposed workaround would allow for that.
Consider a parameter Choice with Alias (display name: value)
Selection1: aaaaa|Selection1
Selection2: bbbbb|Selection2
ParameterFetcher to store the parameter as an attribute _param.
AttributeSplitter on _param by | ->list{0} = aaaaa, list{1} = Selection1
AttributeRenamer so _paramValue = aaaaa, _paramDisplay = Selection1
You can then use either the display name or the value in the rest of your workspace logic.Thanks, yeah I understand what you're getting it. I suppose I'm after a more "elegant" process where the second part is to be hidden from the end user as it is potentially a password or token that I don't want to expose in FME Server.
Could you store the token password as private parameters of type password, and then have a choice parameter with the choices being the names of the private paramters (with or without alias depending on whether the display name make as good parameter name)
Choice =
Selection1
Selection2
--
Selection1 = aaaaa
Selection2 = bbbbbTo be fair, I was thinking the same thing earlier this week. I had:
etc.
The number was important because I wanted it to go directly into an expression [eg Attribute2 = Attribute1 + $MyChoiceAlias)] but at the same time, I wanted the actual choice text to put into a HTML report or label [eg "You chose $MyChoice"].
I think I ended up with the AttributeValueMapper route, but it would have been nice to avoid that, else I end up maintaining the same list of choices/aliases in two different places.
Meant to tag @jdh for her thoughts.
As mentioned below, I use a pipe separated list for the value portion of Choice with Alias, essentially treating it like a tuple, that I can then extract the individual parts.
Usually it's for having both the name and id of the choice, but I have at least one workspace where the value has 6 parts.
What might be a more generic transformer based solution to this and potentially other scenarios, would be a "ParameterPropertiesExtractor" that would return all the properties of the parameter.
ex.
Name: param1
Type: Text
Prompt: blah blah
Attribute Assignment: Default
Default Value: abc
Published: yes
Optional: no
Name: param2
Type: Choice with Alias
Prompt: ipso lorem
Configuration{0}.Display Name: Option 1
Configuration{0}.Value: dolor sit amet
Configuration{1}.Display Name: Option 2
Configuration{2}.Value: consectetur adipiscing elit
Attribute Assignment: Default
Default Value: <empty>
Published: yes
Optional: yesI like that workaround, I actually use that as a conditional in a lot of my REST API workspaces where I have a parameter with options for "Production" and "Debugging" which I use in various places to set values and options in the API calls (ex: disbaling email notifications when set to Debugging or using different API endpoints, etc.).