Converting scripts in stacks to script only stack behaviors

[Ali Lloyd]

On the subject of building UI from script, I generally think it boils down
to whether you already have a good resizeStack handler implemented.  If you
do, you've done all the hard work already - you can just create all the
objects with their required properties before the card opens and delete
them when it closes, and your resizeStack does the rest of the placement
work.

Obviously this is a bit trickier if you have a lot of fields prepopulated
with text, or groups with more complicated structure where it's not so easy
to tease out the scripts into a behavior.

On Sun, Feb 5, 2017 at 6:03 PM Sannyasin Brahmanathaswami via use-livecode <
use-livecode at lists.runrev.com> wrote:

> Trevor, thanks for that intro to the new tools in LC9
>
>
> I'm already using libraries and behaviors extensively, but still find my
> self build LC stack binaries with a full stack script or, quite often,  95%
> of the code in the card script (if the UI can all be done on a single card)
>
> The other day I was thinking 'gee, why not just move this card script out
> to a behavior and assign it to the card."  been mulling this over for a few
> days, the the work flow for making this transition seemed onerous, but LC9
> will make it soooo easy!
>
> Our new app, SivaSiva, is being done with GIT and this is the first time
> working with GIT for something like this… for web and RevIgniter, GIT make
> obvious sense, since the whole environment is text files from the ground up.
>
> But now, with the new app, we have this mix of text only scripts and
> binary *.livecode stacks.
>
> So this leads to two more interesting avenue of adventure/explorations
>
> 1) we are already hitting GIT conflicts with the main stack of the project
> because if one developer needs to add some stack files, or wants to change
> a standalone setting for testing a build on a device, the IDE of course
> requires a Save… so now this stack must be either stashed (assuming you
> don’t need the changes) or committed.. and we hit a conflict later that is
> not so easily resolved.
>
> 2) building UI from script: every now and the notion passes by that
> perhaps building UI from script has advantages of  the LC WSIWIG model. I
> was  intrigued in your to see in the background in sublime text, you had a
> handler that built some of the UI.  perhaps all of it for that dialog box?
> So the question then becomes when, where and why do we make a decision to
> go the route to build UI by script? I guess the one obvious answer is that
> you want to put the UI under git control so that we have, as you put it
> "fine-grained control over changes, edits, history" etc.
>
> I wonder if there are other criteria besides that. Possibly building UI be
> script may be better suited to responsive design, since, in the end, if you
> want responsive geometry, you will end up writing those scripts anyway.
> The only thing missing being the default init props for the control (which
> we normally would create in the IDE) so one must as well "create button"
> and set the default init buttons in the script. Actually it would be pretty
> easy to create the button in WSIWIG and have a small tool to write out the
> initial props that you could then turn into a script.
>
> But this should probably be different thread.  I'm sure HQ has solved
> moved of these issues, but we may need to wait until LC9 is unveiled before
> we get the full picture from the mother ship, until then… I "muddle along"
>
> Brahmanathaswami
>
>
>
> _______________________________________________
> 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