+7
Hi,
I'm struggling with a seemingly very simple task. I want to to check if a user parameter (Text) contains a value using a Tester. I assumed I could just use a Tester and test the $Parameter with the condition "Attribute has a value" but if I run the workspace with a test string it does not pass the test.
The test works as expected if I use a "contains regex" condition instead but I don't understand why "contains a value" isn't working, when the input clearly contains one.
+21
I always try to add Published parameters to the features themselves, it seems more tolerable to handle some of these cases. A workaround at least.
+16
I would actually like to know the answer too. In short, don't use the "has a value", "is empty string", "is null" or "is missing" test clauses directly on parameters. To be safe, use a ParameterFetcher or AttributeCreator to first get the parameter value before using those operators.
A Parameter can never be null or missing - if no value is supplied it becomes an empty string, and you can see this in the log when you start translation. Fundamentally though I think that if you give a parameter a value then you should be able to directly test if it has a value, but you can't.
+7
I would actually like to know the answer too. In short, don't use the "has a value", "is empty string", "is null" or "is missing" test clauses directly on parameters. To be safe, use a ParameterFetcher or AttributeCreator to first get the parameter value before using those operators.
A Parameter can never be null or missing - if no value is supplied it becomes an empty string, and you can see this in the log when you start translation. Fundamentally though I think that if you give a parameter a value then you should be able to directly test if it has a value, but you can't.
Yes, that's what's baffling me as well. Both the ParameterFetcher and the AttributeManager produce the value provided by the user parameter but for some reason that value slips through the tester.
+26
My guess is that when you're testing for "Attribute has value" then it could be that the Parameter gets resolved before the test is performed.
So you'd be testing something like:
"Does the attribute called <Value of your parameter> have a value"
+29
My guess is that when you're testing for "Attribute has value" then it could be that the Parameter gets resolved before the test is performed.
So you'd be testing something like:
"Does the attribute called <Value of your parameter> have a value"
@mark2atsafe could this be something you could write a (deep dive) blog about? the order that things are processed at a function/factory/parameter/attribute level? We've noticed similar behaviour with FME Functions when entered into parameter values, the function will be executed before the parameter value is used
+7
My guess is that when you're testing for "Attribute has value" then it could be that the Parameter gets resolved before the test is performed.
So you'd be testing something like:
"Does the attribute called <Value of your parameter> have a value"
@virtualcitymatt : I thought so too, but why would the regex condition work then? If you test a 3 character string like "abc" and blank space character " " the regex "\\w+" tester only passes the first example. Wouldn't the blank string pass as well, if it was resolved into some other value before the test?
Anyway, I would love to get an explanation on this, like @hkingsbury suggested.
+13
So @virtualcitymatt is 100% correct. When you put a parameter into the Tester on the far left, and then say "Attribute ..." as the test, you're really saying that the far left is an attribute name. Which turns into: "Does the attribute called <Value of your parameter> have a value"
Which is not what you want at all.
What you really want is something we don't have, which would be for us to add a "test" that is "Parameter has a value".
As others have shown the workaround is to fetch the parameter into an attribute, and then test from there.
Regarding the rules around order of substitutions, parameters i.e. $( ) things are always evaluated first, and then functions i.e. @Func things are evaluated next, and lastly whatever results from all that is used to do the work. Nested functions are evaluated from the innermost to the outermost. I think some of the Safers long ago solved the Towers Of Hanoi programming problem in this way. Not recommend but perhaps we should use that one for FME Certification testing one day... :-)
Good question, and good discussion. We'll give thought as to what we could do better here.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
