A little Levure-oriented question

[Graham Samuel]

Thanks for your patience, Trevor. I will stop tyre-kicking now and decide whether or not my particular project work merits taking the Levure plunge!

Graham

> On 22 Feb 2018, at 15:56, Trevor DeVore via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> 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
> _______________________________________________
> 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