I have recently inherited a project that has a fair amount of scripting. The original author (now unavailable), seems to have not understood how to use Gateway Scripts; either that or I’m about to learn something new.
The Gateway has an inheritable project called GatewayScripts, and a few other projects that inherit from it. One project that inherits from it is called Main, and it is set as the Gateway Scripting Project. I can’t see a good reason for doing this, and I’m inclined to untangle this by setting the GatewayScript project to be the Gateway Scripting Project, and find some better use for inheritance.
So, unlike v7.9 where gateway tag events and runScript expressions could only call shared.* functions, v8.1’s inheritance makes it possible to segregate true global scripts (useful in multiple scopes) from the scripts you might use only from tag events. Keeping the latter in a project that inherits from the other is a way to keep edits to your tag event functionality from disturbing your entire gateway.
Thanks @pturmel. Can you provide an example of what the tag event syntax would be for each case? Or point me to some use documentation that shows the distinction in more detail?
I’m trying to envision what a use case/scenario. The only thing I can envision is some Gateway Script function foo() that might be overridden from an inherited function foo() script.
I can’t imagine why I would do such a thing; have such pathological naming for functions.
One of us doesn’t understand the other, I suspect. Let me elaborate:
The situation in v7.x :
Global scripts are all in the shared. namespace while project scripts are in the project. namespace.
Resources in projects, like gateway events, client events, window and template scripting, et cetera, can call any combination of project scripts and global scripts. And project scripts can call global scripts.
Resources outside projects (only possible in the gateway), especially tag events, can only call global scripts (the shared. namespace).
Editing a project script in the designer and then saving the project causes that project’s gateway scripting environment to restart (immediately) and also either notify or push a restart to running clients.
Editing a shared script in the designer and then saving the global script changes causes all projects’ gateway scripting environments to restart (immediately) and notifies/pushes to all projects’ running clients.
The situation in v8.x :
There are no global scripts. The concept has been replaced by scripts in inheritable projects.
The shared. and project. namespaces no longer have any special meaning, and do not exist by default unless a v7.x gateway backup is loaded into a v8.x server. (See the upgrade guide for details.)
Resources in projects, like gateway events, client events, window and template and page and view scripting, et cetera, can call any combination of project scripts of their own and in the full chain of their parent projects.
Resources outside projects (still only possible in the gateway), especially tag events, can only call scripts present in the designated “Gateway Scripting Project”, and its parent project(s), if any.
Editing a script in a leaf project and saving causes that project’s gateway scripting environment (which includes Perspective scripts) to restart (immediately) and notify/push to running Vision clients.
Editing a script in an inheritable project and saving causes an immediate restart of all CHILD projects’ gateway scripting environments (including Perspective) and notify/push to all their running Vision clients.
Key Implications
Tag events in v7.x are ugly because you have to choose between D-R-Y (via shared scripts) for maintainability, versus uninterrupted operation by keeping tag event scripts entirely contained within the tag definition. The latter partially mitigated by scripts defined in UDTs.
Tag events in v8.x can use common script functions while also avoiding the impact on all projects and their clients by using a Gateway Scripting Project that is not inherited by any other project, and contains no UI elements. This is a huge win for production uptime. However, the upgrade process from v7.9 does not leave your v8.x gateway in this condition. You have to separate the [global] project from the upgrade into the parts you need for all projects (and keep it inheritable for those projects) and the parts only needed for tag events. That latter should become a new leaf project, inheriting from the other if necessary, and be set as the Gateway Scripting Project.
Yes, I think we're talking at different levels. You're talking at some post doc level and me at some undergrad level.
I think that's a key statement for what what I'm dealing with. I'm still trying to wrap my head around everything you said, but more importantly, I need to get some more info: specifically, what version are they actually running on (I'll site eyes on this for the first time next week), and if it's 8.x, has been upgraded from 7.x?
I'll probably need to come back to this conversation at some point, or even have a call with a support engineer to better understand.
Hey Phil, informative post which made me ask myself a question:
How I could make use of scripts defined in an isolated scripting project, and what has access to them ?
Is it only tag change scripts ? Can gateway event scripts call them ?
And since I couldn’t find the answer, I’m asking you instead.
By “isolated”, you mean the gateway scripting project as a leaf project? If so, only tag events and similar can call those scripts. If you need to call such from other projects, create message handlers within the isolated project that will call the functions and return their results. Other projects can use system.util.sendRequest to access these handlers.
If by isolated you mean a leaf project that isn’t the global scripting project, then nothing can call those functions except as exposed by message handlers.
Thanks. I did mean a Gateway Scripting Project.
So, If I'm not using tag change scripts (the ones configured directly on tags), then I'd have little to no use of such a scripting project, right ?
Or is the "and similar" part of "only tag events and similar can call those scripts" a bit broader than I think it is ? Can you give an example of one those similar things ?
That looks like a good way to lose your mind though.