What about handlers? Stacks already call preOpenStack and related handlers. Adding handlers that get called automatically would leave it as script only but allow for post-load initialization. I haven't looked to see what is already processed though.
> > On Aug 19, 2017 at 10:58 PM, <Monte Goulding via use-livecode > (mailto:use-livecode@lists.runrev.com)> wrote: > > > > Hi Folks lcVCS was invented before script only stacks and for the most part > script only stacks covers the use case much better. If you have a complicated > stackFile then no matter what text representation we make of it you would get > lost dealing with merge conflicts and diffs. If you don’t believe me try > looking at an Xcode storyboard merge conflict… it’s no fun. You really are > better off just being careful to avoid working on ui stuff on multiple > branches. If you have a trivial UI then you can generate it on the fly as we > do with some stacks in the IDE. If you have something a little bit too > complicated for hand coding generation on the fly then you could use > something like the scriptonlyUI library I experimented with one rainy day > https://github.com/montegoulding/scriptonlyui . Anything more complicated is > just as well off staying a binary file and using script only behaviors for > scripts. Having said that there _are_ a couple of stack properties that we > could add to script only stacks to make things work better and I don’t think > it would be all that tricky to add something YAML like that the engine reads > between the `script “”` header and the stack script. The properties that I > would add are behavior and stackFiles so your script only stack would look > like this: script “StackName” --- behavior: stack “ParentBehavior” > stackFiles: - ParentBehavior: some/path.livecodescript --- command MyHandler > -- code end MyHandler There could be some other properties that would be > helpful but I think these are the critical ones causing issues for behavior > hierarchies which are lost when saving so you need to script them. Perhaps > even stackFiles isn’t that necessary as the stackFiles could be set on a > binary stack elsewhere or the stack could be in a location the engine would > find it. We would probably only want to add properties that we feel are > causing issues which behavior definitely is. The less you add the less chance > of a merge conflict on some change you didn’t intent. Of course once you add > _any_ properties it’s suddenly _not_ a script only stack so… BTW if we only > wanted to add behavior and only stack behaviors at that it might be nice to > just include that in the header: script “StackName” with behavior > “ParentBehavior” command MyHandler — code end MyHandler I actually really > like this option as it’s in keeping with the original faceless script object > concept. Cheers Monte _______________________________________________ > 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
