Script Only Stacks and Script Locals

Sannyasin Brahmanathaswami brahma at hindu.org
Fri Jul 15 21:34:05 EDT 2016


This is important "news"

There is no such thing really as "a" backscript, singular. I was always under the impression that inserting into back would be like concatenating scripts into one giant "backscript"

But what we see now is that every script inserted into "back" is encapsulated, if indeed, as you say… "No… the script locals from "inserted script 1" are not available to handlers in "inserted script 2".

This is important in terms of architecture that seeks to avoid use of globals, but at the same time wants to try to follow "single instance/class " in a MVC framework as much as possible…

which present a challenge in that script only stacks have no custom props which was the "other" way to store persistence data across session/stacks/handlers if you were trying to avoid globals.

But now it seems we've come full circle. Again, it may be my limited vision… but if I have a backscript that, in the current scenario I am working on, fetches data from the server -- in this case an array with all the metadata about a media object we can call into the client side app (but it could be any data that wants to be globally persistant and available)   with script only stacks, we have little choice but to start using Globals again… (with all the headaches that come with that scenario)   if I want aMediaItemData (an array) to be available later or from an independent script only stack the only option will be to

a) store as a custom props in the splash screen/loader stack, and make this a "convention" in your architecture

OR

b) declare in the stack that generates the data

Global aMediaItemData

c) Follow Code Igniter/RevIgniter's lead and set up a single giant global called "gData" array and then this is your spaceship/eggcarton/suitcase for *everything* that needs to persist across controllers/model/views at any time. If one is consistent in nomenclature you know what you have…

So then we have

gData[aMediaItemData]
gData[someOtherArray2]
gData[someOtherArray3]

which may be the best way to go.. most of this data is comprise of small text chunks and not blobs, so from a memory angle it should not be problematic.

I won't be at the conference… I hope it is recorded!

BR



From: use-livecode <use-livecode-bounces at lists.runrev.com> on behalf of Monte Goulding <monte at appisle.net>
Reply-To: How LiveCode <use-livecode at lists.runrev.com>
Date: Friday, July 15, 2016 at 3:12 PM
To: How LiveCode <use-livecode at lists.runrev.com>
Subject: Re: Script Only Stacks and Script Locals


On 15 Jul 2016, at 2:21 PM, Sannyasin Brahmanathaswami <brahma at hindu.org<mailto:brahma at hindu.org>> wrote:
yet to be tested, but interested in caveats
assume script only stack(s)
script "backScriptOne" "  #saved text only as "backScriptOne.livecodescript"
with script locals:
local sMediaMetadata
# more functions
# save to disk
# call and insert into back script
am I correct that now "sMediaMetadata" is a live script local that is private to all functions in backscript?

Yes
i.e not a globals as such, but still available to any other stack commands or functions that may be inserted into back?
i.e. if we insert another lib
script "someBackScriptTwo"  #saved text only as "backScriptTwo.livecodescript"
will sMediaMetadata
be available for commands and functions in backScriptTwo.livecodescript

No

A script only stack is a script file that when loaded is represented by a stack object. It (and its script) behaves the same as any other stack other than no properties of it or objects on it are saved when you save it and it defaults to invisible.

I’m giving a talk on script only stacks at the conference if you are coming.

Cheers

Monte


More information about the use-livecode mailing list