Crazy script-only stack question

[Geoff Canyon]

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 at lists.runrev.com> wrote:

> On Mon, Jan 22, 2018 at 2:20 PM, Geoff Canyon via use-livecode <
> use-livecode at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>