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 <[email protected]> on behalf of Monte Goulding <[email protected]> Reply-To: How LiveCode <[email protected]> Date: Friday, July 15, 2016 at 3:12 PM To: How LiveCode <[email protected]> Subject: Re: Script Only Stacks and Script Locals On 15 Jul 2016, at 2:21 PM, Sannyasin Brahmanathaswami <[email protected]<mailto:[email protected]>> 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 _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
