You can probably get away with doing less work to start, and then just cleaning up any bugs you find in testing.
Essentially the change is this: In your version, the default scope is user, so when you do <@ASSIGN myVar myValue> you are effectively creating that variable in the user scope (as if <@ASSIGN user$myVar myValue>), which is a persistent scope. When you upgrade, the default is changed to request (aka local) and so your unscoped variable assignments will change to the request scope and loose persistency. To correct for this in code, you simply need to add the user scope syntax to your assignments. <@ASSIGN myVar myValue> becomes <@VAR user$myVar myValue> or <@ASSIGN myVar myValue scope=user> It is notable that all versions of Witango and TeraScript support setting the default scope back to the user scope if you wish. It is, therefore, possible to have TeraScript 6.1 operate using the same scoping rules as Tango 2000. This is NOT recommended, however. You should not need to adjust any usages of variables (<@VAR myVar>, <@PURGE myVar>, etc) because the scoping rules will search up the scope hierarchy until the variable is found. The only time this will cause a problem for you is if you wish to have two different variables distinguished only by scope: <@ASSIGN request$myVar yes> <@ASSIGN user$myVar no>. Now if you just do <@VAR myVar> you’ll get “yes” because the request scope is more specific than the user scope. To access the value in the user scope, you would need to use <@VAR user$myVar>. The term ‘local’ is currently a synonym for the term ‘request’. The use of ‘local’ is not recommended, and the term is officially deprecated. I’m not sure exactly when, but in a future release of TeraScript there will be a new scope which acts like a true local scope, and will use the ‘local’ syntax. At such time, you will need to make sure all references to the request scope use ‘request’ rather than ‘local’, unless of course you wish to have a truly local variable. Note that I often used the dollar-sign syntax for scoping: SCOPE$VARNAME. This is the shorthand syntax for providing a variable name and its scope at the same time. While the long hand <@TAG name=”VARNAME” scope=”SCOPE”> is not going to be removed from the platform, the shorthand is recommended. One easy way to update your applications would be to search for the string “<@ASSIGN “ and replace it with “<@ASSIGN user$”. Robert From: WebDude [mailto:webd...@cipromo.com] Sent: Monday, November 21, 2011 2:18 PM To: Witango-Talk@witango.com Subject: Witango-Talk: Scoping Variables Hi Folks, I am currently preparing to upgrade from version 4, probably to version 6 and then up to Terascribe. I remember that syntax and scoping of variables have changed. I am trying to prepare as much of the old files as possible before upgrading. I will probabaly have more questions to come, but I am going to take this a step at a time. First question is concerning scoping variables. Presently, almost all variables are not scoped so I am going through the ardious process of straightening these out. A few questions, if you don't mind... I would assume that you need to scope all <@ASSIGNs Most of the applications have no scope assigned to them presently. Of course, the default for this is "user" in the version I am using, but I am going to go through each assign and scope it appropriately. Almost all are goinmg to be scoped as user, but I have a few that can be scoped as local. Whenever calling on the variable, such as <@VAR blah> I am also going to assume these need to be scoped as well, as is <@VAR blah scope "user"> Do I need to scope any <@PURGE variables? When calling a local variable, should these be scoped as well? i.e. <@VAR blah scope "local"> What exactly is the request scope? This will be for futue reference. It appears to be the same as the local scope. When I upgrade, will I need to change all local scopes to request scope? Is this just a neam change to avoid confusion Thanks for any help! _____ To unsubscribe from this list, please send an email to lists...@witango.com with "unsubscribe witango-talk" in the body. ---------------------------------------- To unsubscribe from this list, please send an email to lists...@witango.com with "unsubscribe witango-talk" in the body.
