Hi Jeff, I think you're right. I can't see a way around this one. I did try to make it a little easier by creating a transformer to use in this situation - but I can't get it to work, even though the mapping file that results from it uses the same syntax that you have below.
In fact I can't get your FME @CopyAttribute function call to work either. Can you send me a copy so I can see what I am doing wrong? Send it to my Safe email address because I don't get yahoo attachments. Thanks Mark --- In [email protected], "Jeff Konnen" <[EMAIL PROTECTED]> wrote: > > 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 > For insights into what's up at Safe Software and what's on the development horizon, visit Safe's blog at spatial-etl.blogspot.com. Safe Software has also made slides available that outline enhancements planned for FME 2007. The slides are from the "Road Ahead" presentation given on Day 2 of the FME Worldwide Users Conference. To view these slides, visit www.safe.com/2006uc. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/fme/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/fme/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
