If the values are known in advance, the best solution is probably to use a published parameter of type "Choice (multiple)". You can the use the ParameterFetcher and AttributeSplitter to convert the space-separated parameter string to a list.
If the parameter values aren't known in advance, you can use a Text type parameter and let the user type e.g. a comma-separated string that you convert to a list in the same way as described above.
If the values are known in advance, the best solution is probably to use a published parameter of type "Choice (multiple)". You can the use the ParameterFetcher and AttributeSplitter to convert the space-separated parameter string to a list.
If the parameter values aren't known in advance, you can use a Text type parameter and let the user type e.g. a comma-separated string that you convert to a list in the same way as described above.
Yes, I am currently using your second suggestion. But since the options seems to be available in the published paramter, I thought I could spare some transformers. But if thats the way, I will keep this solution. 
Yes, I am currently using your second suggestion. But since the options seems to be available in the published paramter, I thought I could spare some transformers. But if thats the way, I will keep this solution.
Unfortunately there is no way of automatically mapping a published parameter to a feature attribute list. But it could be a very nifty extension to the ParameterFetcher, so why not create an idea.
Unfortunately there is no way of automatically mapping a published parameter to a feature attribute list. But it could be a very nifty extension to the ParameterFetcher, so why not create an idea.
I do not want to do it automatically. I want to set up fixed Published Parameter, fetch them with the ParameterFetcher and use them as an input for a Python Caller. A college of mine first set this up with an Excel Reader and transformed the input into lists, but we thought this to be a rather impractical solution. So I changed it to the use of Published Parameter, since I had seen that there is this "Attribute List" option available. But yes, the idea of extending the ParameterFetcher's capabillities could come in handy for other cases :-)
I do not want to do it automatically. I want to set up fixed Published Parameter, fetch them with the ParameterFetcher and use them as an input for a Python Caller. A college of mine first set this up with an Excel Reader and transformed the input into lists, but we thought this to be a rather impractical solution. So I changed it to the use of Published Parameter, since I had seen that there is this "Attribute List" option available. But yes, the idea of extending the ParameterFetcher's capabillities could come in handy for other cases :-)
Why not simply pass the name of the list as a parameter?
Why not simply pass the name of the list as a parameter?
Sorry, I am not that experienced in FME, so I dont really understand what you mean by that. If I only pass the name, how do I get the values into the PythonCaller?
If you pass the list name as a string into a custom transformer, first use a ParameterFetcher to get the list name into a regular attribute, e.g. '_my_list_name'. Then in your python code, do something like this to retrieve the list values and iterate over them:
list_name = feature.getAttribute('_my_list_name')
list_values = feature.getAttribute(list_name + '{}')
for value in list_values:
# do something with each list value
If you pass the list name as a string into a custom transformer, first use a ParameterFetcher to get the list name into a regular attribute, e.g. '_my_list_name'. Then in your python code, do something like this to retrieve the list values and iterate over them:
list_name = feature.getAttribute('_my_list_name')
list_values = feature.getAttribute(list_name + '{}')
for value in list_values:
# do something with each list value
The list is defined inside the custom transformer, so that every Workspace that uses this transformer uses the same values in the list and if they need to be changed, every linked Workspace gets the update. So passing the list name into the custom transformer would require to first define it. It feels rather complicated, when I rather want to have the defintion of the list and its values inside the Custom Transformer and the values are static.
Maybe I should explain in more detail, what I do with this:
When publishing Workspaces from FME-Desktop on FME-Server, we need to alter specific folder paths since we use a Linux-Server. So the Custom Transformer uses a list of RegularExpressions that we have defined as Published Parameters and an input from the main prozess with the folder paths to transform these paths within the python script for the useage on the FME-Server. Since we want the custom transformer to the same job in every workspace, only the input from the main prozess is dynamic.
The list is defined inside the custom transformer, so that every Workspace that uses this transformer uses the same values in the list and if they need to be changed, every linked Workspace gets the update. So passing the list name into the custom transformer would require to first define it. It feels rather complicated, when I rather want to have the defintion of the list and its values inside the Custom Transformer and the values are static.
Maybe I should explain in more detail, what I do with this:
When publishing Workspaces from FME-Desktop on FME-Server, we need to alter specific folder paths since we use a Linux-Server. So the Custom Transformer uses a list of RegularExpressions that we have defined as Published Parameters and an input from the main prozess with the folder paths to transform these paths within the python script for the useage on the FME-Server. Since we want the custom transformer to the same job in every workspace, only the input from the main prozess is dynamic.
I'm not quite sure I understand the problem. You do not need to "define" the list as such, FME is not like statically typed programming languages where attributes are formally defined somewhere. You can think of FME attributes as named keys with an associated value, much like a dict in Python. Like Python, FME only tries to resolve the key names at run-time. So if you pass a string into the custom transformer that contains the name of a list or some other attribute, the code inside the custom transformer will try to resolve the list or attribute name on the current feature. The list or attribute may be there, or not, depending on the actual data being processed, FME does not need to know before the code runs.
Let me know if I'm misunderstanding something.
I'm not quite sure I understand the problem. You do not need to "define" the list as such, FME is not like statically typed programming languages where attributes are formally defined somewhere. You can think of FME attributes as named keys with an associated value, much like a dict in Python. Like Python, FME only tries to resolve the key names at run-time. So if you pass a string into the custom transformer that contains the name of a list or some other attribute, the code inside the custom transformer will try to resolve the list or attribute name on the current feature. The list or attribute may be there, or not, depending on the actual data being processed, FME does not need to know before the code runs.
Let me know if I'm misunderstanding something.
Maybe these picture help to illustrate it:
This is the describes CustomTransformer, fetching Published Parameters defined as comma-separated text as suggested.
This Transformer is then included in a generic workspace assembling the configuration data for a WorkspaceCaller/JobSubmitter that will be used as a template for many processes. Using a tester with another Published Parameter, the user is asked wether the Workspace will be run on the server or not and if the paths need to be updated. If thats the case, the configuration data is transformed accordingly before being submitted to the workspace runner.
The transformer uses RegEx with definitions based on the parent folders (only a few) where we store data processed in the FME prosess in a strict structure to identify the configuration parameters that need to be updated and updates them. While the folder paths, namely the child folders, can change in the configuration data for each workspace, the parent folders and therfore the RegEx is static. Thats why we thought it to be a good way to store them in a static list, inside the custom transformer where it can be changed centrally and applies to all workspaces where we use this transformer for the configuration of a WorkspaceRunner.
While I am not fully sure what your question was aiming at, I hope this somehow answers it. I think that I dont really understand where the advantage of parsing the name of the list would lie, since its not a part of the config data so far and I would have to include it at some point.
