I agree that having the ability to use stacks (script-only in particular) for behaviors is nice -- it lets developers easily put all their code under source control. But the implementation is flawed, as we've discussed, because it doesn't support (native, transparent) chaining of behaviors, and so is a feature-deficient replacement for button behaviors.
In looking at the bug for this -- which is a year and a half old -- I thought of the idea that app layout could also be under version control if it, too, had text-based alternative. There's a bug for (roughly) that -- and it is over five years old. So what I'm suggesting is that it seems unlikely that either of these issues will be fixed in the engine anytime soon, and further that it doesn't necessarily have to be an engine change that addresses it. The code library to make this happen would be almost trivial to write an MVP for. A simple format (I'd suggest JSON, but newline support seems to be an issue) would allow starting with a really basic definition, just enough to support stacks with scripts and properties, which would get us the equivalent of script-only stacks with chained behaviors. Beyond that it would quickly be possible to include cards, groups, and controls, with many (most?) properties, in external files, and voila, source control over the interface for many projects. I'm probably under-thinking the complexity, and overthinking the possibility/need, but I definitely want a standardized way of handling chained behaviors in source control, and I'd hate to wait another year and a half to get that one thing. And: yeah, openstack is a bad idea for the initialization message. It would be much better to use a custom message -- behaviorStack? gc On Mon, Jan 22, 2018 at 12:47 PM, Trevor DeVore via use-livecode < use-livecode@lists.runrev.com> wrote: > On Mon, Jan 22, 2018 at 2:20 PM, Geoff Canyon via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > Is there any reason script-only stacks had to be implemented in the > engine? > > > > It is nice that you can store the scripts for controls in a UI stack > alongside of the ui stack file. You just set the stackfiles property of the > UI stack and then opening the UI stack opens up all of the behavior stacks > that the UI stack requires without any extra effort on the part of the > developer. > > > > Is there any reason *not* to implement their equivalent in about five > lines > > of code in the mainstack of a project? i.e., > > > For some cases dispatching a message can be useful. I don't think I would > use `openStack`, however, as that doesn't describe the event that is > occurring. You are just loading the stack into memory. A script only stack > can create a UI and may expect the `openStack` message to be dispatched at > the proper time and in the proper sequence relative to other messages that > are sent when actually opening a stack. > > I wouldn't load all of my script only stacks that way, however. I use > script only stacks in a variety of ways. For libraryStacks they already get > a `libraryStack` message. If I'm using them as behaviors for controls in a > UI stack then they are automatically loaded by the engine for me as > described above. In the majority of cases that doesn't require any extra > work. In the Levure framework you can specify that a stack file will be use > specifically as a behavior. In the case Levure will dispatch a > `LoadBehavior` message to the stack and it can assign itself a behavior. > > My preference is for the ability to set a script only stack behavior in the > script only stack itself. > > -- > Trevor DeVore > ScreenSteps > www.screensteps.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
