Skip to main content
  • EN

I want to ask the community about "expected behaviour" of something.

 

 

I use AttributeCreator to create Failed_Reason - it contains a value "1" (number one).

 

 

So at this point @Value(Failed_Reason) = 1.

 

 

This goes into a customTransformer. The customTransformer has a PublicParameter which points to Failed_Reason as an attribute using the "Attribute" type.

 

 

Here's where things get confusing.

 

 

Inside the customTransformer, if I use the ParameterFetcher, to return $(Parameter) I get "Failed_Reason" as a text string! Not 1.

 

 

I get the same result if I pull it directly into a StringConcatenator for instance.

 

So $(Parameter) = "Failed_Reason" (utf-8)

 

 

On the other hand, if I put the parameter into a 2DPointReplacer, it works.

 

 

But it gets worse!

 

If I place an empty "attributeKeeper" before the 2DPointReplacer (so all attributes are now removed), it stops working. Why? Well, because the attributeKeeper is removing the attribute that the parameter is pointing to. Even though inside this customTransformer that Attribute has never "existed". The Parameter itself still exists.

 

 

 

In the past few days I've been bitten by this twice in slightly different ways - I didn't even realise it was the same thing until today!

 

 

 

The TL;DR version is:

 

 

Does the community think Attributes in PublisherParameters should function as pointers (like they do now), or actually transparently contain the value of the attribute.

 

I lean strongly towards the later.

 

 

(FME2013 SP1)
Hi,

 

 

I kinda agree with you on this behavior being somewhat unclear, although I don't really see much of a problem in practice.

 

 

It is easy to use the parameter to either get the name "$(myParameter" or the value "@Value($(myParameter)". You also have the AttributeDereferencer that does the same thing.

 

 

Also, be aware that sometimes you actually may want the parameter names rather than their values.

 

 

All in all, I personally find the current implementation both flexible and easy to use.

 

 

David
Well, now that I know how it works, I can better use it (although the fact that sometimes ParameterFetcher returns the Attribute value, and sometimes the Attribute name and I don't know why isn't useful).

 

 

My thinking is more that its very non-obvious and doesn't follow the convention for how FME usually passes stuff around.
Hi Jonathan,

 

 

I also agree such a behavior could cause confusion sometimes. When I need to get an attribute value through 'Attribute Name' type parameter, to prevent the confusion, I often create a new attribute in a custom transformer by AttributeCreator rather than ParameterFetcher. For example, the settings are: Attribute Name: _failed_reason Value: @Value($(Parameter))   After this, I can use '_failed_reason' to get the value which the parameter value (i.e. an attribute name) is pointing to.

 

For your information.   Takashi
Turns out there's also an FME Evangelist on it - about half way down: http://evangelism.safe.com/fmeevangelist112/

 

 

Their use case seems to be quite different from mine and Takashi's.
Hi Jonathan,

 

 

Thanks for the information.

 

Their case is also using the syntax of '@Value($(PARAM_NAME))' to get the value of the attribute, I think the mechanism is not different from ours.   When the parameter type is 'Attribute Name', -- '$(PARAM_NAME)' represents an attribute name, -- '@Value($(PARAM_NAME))' represents the value which the attribute name refers to. Let's keep this in mind, all is going well 🙂

 

Takashi

Reply


Community Stats

30,147
Posts
114,430
Replies
37,790
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.