Crazy script-only stack question

[Geoff Canyon]

Yeah, the five-liner is intended only as a way of implementing script-only
stacks with behavior chaining in code rather than the engine (since that
doesn't seem forthcoming. It seem many people are doing something very like
this, at a basic level I'm just proposing that standardizing would be
useful. But the next step would be to support something more robust than
just "line 2 through -1 is the script of the stack". It wouldn't take much
to be able to put much more of a project into source control. But I agree
that there is far more need for the already-available source control of
scripts.

On Mon, Jan 22, 2018 at 12:56 PM, Sannyasin Brahmanathaswami via
use-livecode <use-livecode at lists.runrev.com> wrote:

> Not barking up the wrong tree at all, with multi-stack apps very much in
> the wind…a subject of interest indeed. Agreed with Igor, (ala bug 10275_)
> not having and a RCS for the binary stacks themselves is a nuisance. But
> your 5 liner doesn't solve that either.
>
> But how does creating a stack and setting it's script to a text file
> different from adding a stack to your framework and then setting the
> behavior of that stack to the text only script?
>
> Or put another way, what advantage would it have over the behavior of the
> stack?  And since your newly created stack has no controls, those would all
> need to be created by script and this is exactly what LiveCode provides:
> WSIWG layout environment (albeit needs a lot of work to get to 2018
> standards )
>
> A case can be made for treating the binary stacks as a "view" Typically
> there is a split in the team between design and code. This is also
> happening universally where designers are doing UI/UX prototypes in
> InVision Or Zeplin.. (no code)  and push these over to the code team.
>
> We have such stacks in the SivaSivaApp. where there is almost no code in
> the stack at all. We use "the target" …in the text only behavior stacks…
> this is working pretty well as once the eye candy and UX is locked in, we
> are not touching that too much, if anyone is, it's usually just one person,
> so pulling and pushing the binary from GIT is not that big a deal… conflict
> wise… of course if some others on the team *do* want to touch the UI, then
> it gets messy
>
> BR
>
> On 1/22/18, 10:21 AM, "use-livecode on behalf of Geoff Canyon via
> use-livecode" <use-livecode-bounces at lists.runrev.com on behalf of
> use-livecode at lists.runrev.com> wrote:
>
>     Is there any reason script-only stacks had to be implemented in the
> engine?
>
>     Is there any reason *not* to implement their equivalent in about five
> lines
>     of code in the mainstack of a project? i.e.,
>
>     on loadTextStack tFilePath
>         put url ("file:/" & tFilePath) into tStackData
>         put line 1 of tStackData into tStackName
>         create invisible stack tStackName
>         set the script of stack tStackName to line 2 to -1 of tStackData
>         send "openStack" to stack tStackName
>     end loadTextStack
>
>     This would immediately fix the issue of chained behaviors, and allow
> for
>     the incremental implementation of a far richer format for text-based
> stack
>     storage, leading to gains in project-definition source control.
>
>     Given that Bug 10275 <http://quality.livecode.com/
> show_bug.cgi?id=10275> is
>     over five years and several versions old, am I barking up a tree with
> this,
>     or making sense?
>
>     with no clue,
>
>     Geoff
>
> _______________________________________________
> 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
>