> On 16 Jul 2016, at 11:34 AM, Sannyasin Brahmanathaswami <[email protected]> > wrote: > > 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 isn’t anything new so I guess you had a mistaken understanding of the message path here. The same is true for frontScripts and library stacks. In fact there is also the issue that if multiple frontScripts implement the same handler then the one that gets to handle it is basically just the most recently inserted that gets to handle it. > > 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. They do have custom properties the same as every other object but they aren’t saved. > > 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 This is not true. You can use custom properties in script only stacks as I said above but my preference is to use a handler to get the data from a script local as custom properties suffer from the same issues as globals where it can be too flexible what scripts are messing with them. > > > I won't be at the conference… I hope it is recorded! It will be there is a simulcast available. 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
