Hi,
in FME 2014 there are a couple of new published parameter types that might be of interest. Here is one of them:
The ListExploder (for "_attribute_list") and the AttributeDereferencer might also be relevant.
David
Thanks David.
Actually our problem is not really to get values; but to tell what we want.
If it was python, solution 1 is:
for f in all_features:
my_ct(param1, param2, f.foo, f.bar, f)
def my_ct(param1, param2, foo, bar, f):
f.foo = foo
f.bar = bar
do_something(f.foo, f.bar)
Solution 2 is: for f in all_features:
my_ct(param1, param2, f)
def my_ct(param1, param2, f):
do_something(f.foo, f.bar)
What I would like is something to have solution 2 AND tell the user wich parameters I'm using (if it's possible).
If not, what is the "best" solution / good practice / better for performance / better for buritos etc... ?
Sounds like you should have a good look at the PythonCaller, it might just offer you the flexibility you need.
The API is documented under <FME install>/fmeobjects/python/apidoc/index.html
David
David,
I know Python and I know about PythonCaller, that's not why I'm searching for.
I used python to illustrate what I want.
My problem is how can I work with users, and share my CustomTransformers without them to have to know how it's done.
Hi,
have you looked at how it's done in the FME Store (
http://fmestore.safe.com/transformers.htm)? Should be good for a few ideas.
David
Hi,
As my personal guideline, I basically receive feature attribute values through Published Parameters in order to keep generality and maintainability of the custom transformer (except embedded one for a specific workspace).
Probably my thought is common to your "solution 1". But I don't think it's always necessary to copy attribute values using the AttributeCreator. In many cases, you can refer to a parameter value (i.e. feature attribute value) via parameter name e.g. $(PARAMETER_NAME). So I think it's rare that you cannot avoid "ugly" workflow.
What kind of case are you assuming?
Takashi
Thanks Takashi,
My "ethical problem" with parameters is that I consider them as some kind of "constant" in my process.
For exemple: user id/pwd for data connection etc...
In my case, a feature is a row in DB; and I get the ID of each row as parameter for my CT (well, obviously, I ask for it).
So the CT become "like" a specific process for each feature, and not a part of the "flow".
For me it's awkward.
That's why, I prefere to create attribute for the feature.
The other positive effect of having feature attribute (and not parameters) is that every task in FME work with attributes and can highlight missing attributes.
Alex
An attribute name can be also treated as a parameter value (Parameter Type: Attribute Name, FME 2013+). And you can fetch the value which is associated to the attribute name with "@Value($(ID_ATTR_NAME))" in parameter settings of transformers.
Does this mechanism help your case?
Thanks Again Takashi.
Actually that's the way I'm doing things in my solution 1/
Followed by an AttributeCreator that does this:
Attribute Name: ITEM_ID # <- so I know the attribute I want
Value: @Value($(ID_PARAM)) # <- the asked parameter
And so I've got my attribute in my feature.
That's an intelligible way, I don't think it's "ugly". But in many cases, I use the parameter name directly in any transformer parameter setting.
e.g.
Group By: $(PARAM) (refer to attribute name for grouping)
ID_@Value($(PARAM)) (refer to attribute value for string concatenation)
etc.
