A little Levure-oriented question

[Trevor DeVore]

On Thu, Feb 22, 2018 at 7:25 AM, Graham Samuel via use-livecode <
use-livecode at lists.runrev.com> wrote:

> 2. When I’ve used behaviors myself, it’s to allow essentially the same
> script to be used for many objects, with the extremely useful ability to
> hang on to the local context: I once used behaviors for cells ina
> spreadsheet-like display, for example - whereas in my current example, I
> proposed that the Big Green Button was unique and wouldn’t want to share
> its primary handler with anyone else (though of course it would probably
> use some common library routines in any complicated set up). If in my
> example there was a Big Red Button, it would have an entirely different
> function from the Green one, so there would be no room for the shared code
> a behavior provides. So the use of behaviors in this kind of setup looks
> kind of forced to me. But perhaps I am overestimating the extent to which
> behaviors come into the picture.
>

Whether or not it is forced depends on your goals.

I have two goals - manage my app using git and be able to edit all scripts
in an external text editor (I use Sublime Text). If I don’t move the button
behavior out into an SOS then it won’t play well in my text editor. As an
example, two days ago I was cleaning out unused code in a project. In
Sublime Text I searched my project for calls to a handler. The handler was
called from a couple of button scripts inside of a binary LiveCode stack
file (I had not converted every script in the stack to a SOS behavior). In
the search results in Sublime Text I couldn’t see what the actual script
was, just that a binary file had a reference to the string I was searching
for. I want to be able to read the script. Also, if I end up changing the
button script (I’ve been known to rename handlers if I want to clarify what
it does) then I want my git history to show me exactly what changed. If I
save the script as part of a binary stack I can’t see what changed. If I
store the script in an SOS then I can.


> Changing the subject a bit, I once wrote a very simple DC circuit
> simulator, in which there were different components like a light bulb, a
> motor, a buzzer etc. When the user ‘switched’ the circuit on (by clicking
> on an object representing a switch), the program sent the same message -
> “applyVoltage”-  to each object. Each object had its own applyVoltage
> handler (method, in O-O parlance) for reacting to the circuit going live,
> so the bulb lit up, the motor rotated etc. This is kind of the inverse of
> the behavior idea - this is the same message being sent to multiple objects
> rather than multiple objects using the same script. I wonder how a
> Levure-framed app would deal with such a structure. Perhaps it wouldn’t
> notice at all.


Whether or not you use Levure would have no effect on how you solve this
particular problem. Levure encourages the developer to organize your stacks
using the file system and to organize stacks within folders based on how
they are used (window, library, behavior, etc.). One benefit of following
Levure’s suggestion is that your app becomes more VCS-friendly. How you
organize objects on your cards or architect solutions to problems such as
this falls outside the scope of Levure.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.com