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] 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] [mailto:[EMAIL PROTECTED] On Behalf Of > Jason Birch > > Sent: 2 mai 2007 19:08 > > To: [email protected] > > 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 > > > > > > > > > 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/
