> Seriously, this change in behaviour means that we _really_ need to
test workspaces thoroughly when upgrading the transformers, and make
sure to make backups first. Depending on our test/upgrade cycle, it
also may mean there are times when functionality that we relied on in
the past is no longer available when creating new workspaces or
modifying existing ones, and there is no analogous function available.
Yes - most of the time when a change is made the old function still
works - but I don't know how you can close a hack like this yet still
make old workspaces operable. Oh - I guess as long as you don't update
the transformer and leave the settings as they are then it will be OK.
Thankfully (for me) that's a puzzle for the developers to work out :-)
> The counter hack that Dale demonstrated is invaluable, and I've seen
you post similar solutions in the past using the same functionality.
Can you think of a way of exposing this function? In order to avoid
namespace collisions, we should be allowed to specify both a prefix
and an attribute to use in counter generation. Can this be worked
into the Counter? If not, can we have a transformer naming contest? :)
My favourite is to expose that as a 'Group-By' in the Counter - since
that's what it's really doing.
I think the 2007 beta Counter also has an option to use it locally or
globally, which also helps enormously in the naming of Counters.
Mark
> Jason
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/
