Ahh... so code that has object level scope should be e.g. "tiny-little-nav-buttons.livecodescript"
That is set as the behavior for those buttons? and code that has things like "getLocalAppPath()" should be in " start using stack "coreAppFunctions.livecodescript" Is that what you mean? @ Mark, Monte, Peter (brett) if you are inspired -- a tutorial on "building an app from scratch, using the script-only modular approach to the max." as a video tutorial or something would be fantastic... ala the old "sheep herder" video that Ben did. It doesn't have to be complicated or too long... just point us in the right direction. I'll start testing, hacking today, but for newbies who are coming from Ruby, Python, PHP, JS CSS etc... such a tutorial would make a lot of sense... -- how all the pieces fit together... @Mark, you blog post was great... take it one step further! Like if you create a substack it is saved automatically in the binary, but if I am in an app in the IDE and create a script only stack.. will it be automatically loaded later when I reboot my app in the IDE? OR do we need to manually script the "start using" those stacks, even though we created them in the app just like a substack? and what is the engine's scope for finding them? Pathwise: does it automatically look for the script only stack in the default folder and is that for the LC engine? or the folder that contains the stack that from which the script only stack was created? Or should we set up some folders in that ala the JS apps or PHP ... functions, core, object-behaviors etc. where script are stored and then in the app we explicity have a function to find those libraries/behaviors script-only stacks Of course I'm going to figure all this out in the next few hours, but it would be great if it were "tutorialized." And, since LC team has been doing this already for some time... best practices guide would be ideal. I've been studying Google Material Design docs and impressed by the level of "instruction" they give for best practices. it's pretty awesome... Someday, something like that for LC, created by all you LC wizards would be a) really give a leg up for a generation of "code only programmers" who might like to adopt LC b) help us do it right from the beginning. yeah, I know.... "coding is easy, documention is hard (smile) On March 28, 2016 at 5:55:42 PM, Monte Goulding (mo...@appisle.net<mailto:mo...@appisle.net>) wrote: Yes, it was the mix of code that should have an object scope and code that was fine to have a application wide scope that I was commenting on Matt. Sent from my iPhone > On 29 Mar 2016, at 2:46 PM, Richard Gaskin <ambassa...@fourthworld.com> wrote: > > Matt Maier wrote: > > > Monte got annoyed that I did something like that instead of setting > > behaviors. So it might be better to write behaviors in script-only > > stacks and then set them onto the various controls, rather than > > managing the controls all the way from the library stack(s). > > Behaviors are good. And so are libraries. They're not mutually exclusive. > > "Nothing is true. Everything is permitted." > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for Desktop, Mobile, and Web > ____________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
