Hi Dale,
I think that the place where we will miss it most will be in custom
transformers.
Imagine the following:
We read featureclasses and write them into splitted tables, where we have
each time two tables:
One with the attributes and one with the geometry.
In the destination geometryclass, we would have a ForeignKey which is always
the name of the original featureclass + let's say "Ref".
Today, this is easy:
We create a custom transformer with One Input and Two Outputs.
In the first one we route the attributes, in the second one the geometry +
we create an AttributeCopier copying the OBJECTID into (and that's where it
get's tricky....) @Value(_tempClassName). _tempClassName is a Concatenation
: &fme_basename + "Ref" => With this custom transformer we can automate the
mapping between hundreds of input and output featureclasses. We create the
Custom Transformer once and use it 100 times. Thanks to this "hack" as you
might call it.
Without the hack, I would not know how to copy the Attribute OBJECTID into a
"dynamic" attributename ...
Perhaps with a FMEFunctionCaller
@CopyAttributes(@Value(_tempClassName),OBJECTID).
Could Work ...
Well ... I just tested it and it works ....
Now I am wondering if I should send this mail, as I found it out myself ...
I guess, there are more people that are wondering how they could do this, so
I'll send it :)
Greetings,
Jeff
On 5/3/07, Dale Lutz <[EMAIL PROTECTED]> wrote:
Hello Daniel,
> > Please, tell me we wont!
You won't.
You'd written:
> > Gasp!
> >
> > I'm getting really nervous reading these lines. We have entire
> production processes (Hundreds of workbenches) that use
> &attributename, @value(attributename) or $(macrovalue). Does it mean
> we are going to have to modify all our workbenches to keep moving with
> new releases ???
As Richard Nixon said (maybe that is a bad reference) "Let me make one
thing perfectly clear..." The rule that we have at safe is that if you have
something working now, it will always continue to work. That is a "no-ship"
criteria for our testing.
Now, that is not the same thing as saying "if I used to be able to create
a workspace from scratch and get away with x, I can still create a brand new
workspace from scratch and do exactly the same thing". Another quote -- from
the Australian movie Muriel's wedding: "You can't stop progress". We have to
be able to make changes and adjustments and what we feel are improvements,
and sometimes, this means that the way you do things has to change. But
we've got mechanisms for making progress in this way so that old things, old
workspaces, still work.
If you want to know how, all transformers have a "version#" associated
with them, as do even "constants" typed in. So that's why things continue to
work that are "old", even if the new version that you'd place down won't. We
added in FME 2007 the ability to actually see the version #s of your
transformers, but in general we think folks shouldn't know or care.
Now, back to the question in hand. If you have old workspaces that used
@Value/&attr/$(mac), they'll still work. And you can edit them, etc, and
they'll all be okay. But if you place down a new transformer or constant,
the new protective rules will apply to the new constant or transformer. (You
can always copy or duplicate your old one if you're addicted to the old
behavior though).
So how can you do what you used to if you are starting from scratch? In a
bit less tricky and more obvious way, we think. For $(mac) -- you can use
the ParameterFetcher. For @Value/&attr, you could "manually" expose whatever
attribute you wanted to deal with by just right clicking on a transformer
upstream, saying "Add Attribute", typing in the name, not connecting any
constant to it, then just using it in subsequent transformers.
And if you're desperate, you can always use the new FMEFunctionCaller,
which absolutely touches nothing and passes whatever you typed into it
straight into the underlying FME mapping file/engine untouched. This is a
more obvious way of getting into the core FME, if that is what you want.
We are quite certain that these new ways of doing things are in many
respects better, more self documenting, and all around less tricky that
getting at the older FME syntax from within workspaces and have the side
effect of making it easy for you to search and replace ( ) or $ or & or @
when you really want those things.
We welcome feedback on situations and cases where this may not work well
for you, because it is our goal to make your experiences in using FME the
most fun and productive possible.
And besides, with these changes, the support folks at Safe "won't have the
FME parser to kick around anymore..." (I should offer a Safe Spork to anyone
that writes in and tells me what I'm referring to there...)
Dale
----------------------------------------------------------
Dale Lutz Safe Software Inc. [EMAIL
PROTECTED]<dal%40safe.com>
VP Development Surrey, BC, CANADA phone: (604) 501-9985
http://www.safe.com fax: (604) 501-9965
----------------------------------------------------------
> >
> >
> > Daniel Bégin
> > Canada center for topographic information - Sherbrooke
> >
> > ________________________________
> From: [email protected] <fme%40yahoogroups.com> [mailto:
[email protected] <fme%40yahoogroups.com>] On Behalf Of
> Jason Birch
> > Sent: 2 mai 2007 19:08
> > To: [email protected] <fme%40yahoogroups.com>
> > Subject: RE: [fme] Variables and AttributeCreator
> >
> >
> >
> >
> >
> >
> > Jeff wrote:
> >
> > > I'd like to stress that this kind of working, with &attributename
> and
> > @Value(Attributename)
> > > inside of Transformers is very important for us and we'd not like
> it
> > to disappear!
> >
> > I had some lengthy discussions with Safe staff just before and
> during
> > the UC.
> >
> > The long and the short of it is that they appear to be fixed on
> doing
> > away with these "hacks" in order to insulate users from unexpected
> > results when placing these special characters (&, @, etc) within
> > transformers without knowing what they do.
> >
> > They did commit to ensuring that alternative means of accessing
> these
> > items would be developed as required, so if you're missing something
> > make sure to let them know asap.
> >
> > Jason
> >
> >
> >
> >
>
--
Jeff Konnen
INSER SA
Switzerland
+41 (0) 21 643 77 11
