Hi Jason,
--- In [email protected], "Jason Birch" <[EMAIL PROTECTED]> wrote:
>
> This is just a general comment, but quite a few of the performance
> hacks for workspaces are rather arcane, and based on understanding
> how the Workbench tool generates the underlying mapping file.
> Features like this one, which rely on something extremely ephemeral
> like the order you draw the connections, are really not worth
> messing with and, I would argue, should either not be exposed in
> Workbench, or should be made more obvious.
True - and I didn't even know about the draw-connection order until a
couple of weeks ago. But in this case feature order would make a HUGE
difference in processing, so it needs to be there. On the other hand,
why make it too obvious when 99.9% of workspaces won't use it?
The challenge is to expose features like this just enough to stimulate
the user into looking it up. I think that's what the Bases First
setting should do. It'll still work without, but more efficiently
with. The aim of the training course, for example, is not to teach you
everything, but show you what to look for and where.
In this case - would it help to show in the workspace what order
datasets are read or reach the transformer? To be fair our Workbench
team is doing a great job of gradually exposing all items like this,
but if you can think of a way to make some of these oddities more
obvious then let us know.
> The reason that I say this is that if I get hit by a bus and the
> person who replaces me doesn't have this knowledge, then an act as
> simple as disconnecting and reconnecting a transformer will break
> the workspace in a non-obvious way. There's a lot to be said for
> well-documented workspaces (VERY pretty example by the way Mark),
Thank you - but that's best practice for you. If you simply label the
connections like this it doesn't matter if you do get hit by a bus.
Not to your office anyway, and hopefully your local emergency services
also use FME!
> It would be much better if Workbench automatically sensed the cases
> where it should apply this kind of optimisation and just do it
> behind the scenes.
No joke - FME does a great deal of work "automagically" to make sure
translations are optimized. I'm sure we could even do this - though
when to tell if the user is intentionally not doing this is a problem.
> If the problem is the link to the mapping file, perhaps mapping
> files should be deprecated in favour of something more flexible.
> That last sentence was a joke. Just a little high-sticking. :)
>
> Jason
Then I'm afraid our server is going to zap your FME license with a two
minute penalty.
Mark
Join us at the FME Worldwide User Conference Sept. 21-22, 2006 Vancouver BC
Canada. For more information, 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/
