Script Only Stack Architecture

[William Prothero]

Thanks, Richard:
My previous exposure to the behaviors methodology was in Adobe Director. A behavior was assigned to a particular control, field, button, whatever, and in its script, it defined a set of properties that could be set custom for each instantiation. That way, a “set” of graphics for a button, for example, could be assembled as part of a behavior where the “up”, “down”,”over”, “disabled” etc, states linked to a particular graphic. Of course, you don’t have to do that in Livecode, but that was the idea.

Thanks for the prescription. I’ll try it out. 

Let me know next time you’re in Santa Barbara. I’ll treat you to lunch.
Best,
Bill

> On Mar 31, 2016, at 9:52 AM, Richard Gaskin <ambassador at fourthworld.com> wrote:
> 
> William Prothero wrote:
> 
> > Reading this kinda makes my head spin. Now I’m thinking it is going
> > to be a heck of a lot more robust for my situation, as a single
> > developer, to not use behaviors at all, but to have a single
> > (possibly script only) substack that holds all of the handlers that I
> > would normally use as behaviors, and just put a call to that handler
> > in each button. I can use “the target”  or “me” as a passed variable
> > to make the action specific to a particular control.
> >
> > This approach seems a lot less prone to idiosyncrasies and more
> > easily transportable to other apps, to me. It also means that all of
> > my “behavior type scripts” would sit in a single script-only stack,
> > which would make it a lot more convenient to access and edit than a
> > bunch of small script only stacks sitting in my project browser.
> >
> > Am I wrong. misguided, foolish, or brilliant?
> 
> Behaviors are very powerful for all sorts of things, whether you work alone or in a team of twenty.
> 
> The biggest benefit for teamwork comes from the very separate question of whether to use script-only stacks to define behaviors.  Script-only stacks are an ideal solution for Github-based workflows, but have minimal value (some, but not as much) for anyone not dependent on a version control system designed for other languages.
> 
> Ditch script-only stacks for now and continue to explore behaviors. You'll thank me.  You'll want to buy me lunch next time I'm in Santa Barbara.  I'll accept.  Behaviors will change everything, very powerfully, the more you explore and use them.
> 
> Once we step away from the very separate issue of script-only stacks, we have really only two guidelines for using behaviors effectively:
> 
> - A behavior definition can be any button or stack.
> 
> - When using behaviors, the object containing the behavior script
>  must be in memory when anything relying on it is brought into
>  memory.
> 
> That's it.
> 
> When exploring a new feature I like to make a simple stack I can use as a playground to poke around and experiment without mucking up anything important I'm working on.
> 
> Here's a quick tutorial that may get you hooked on the power of behaviors:
> 
> 1. Make a new stack titled "Behavior Playground"
> 
> 2. Add a button named "MyClass"
> 
> 3. Set the script of that button to:
> 
>    on mouseUp
>       answer the name of me
>    end mouseUp
> 
> There - you've just created a behavior, defining an action for what will be an entire class of custom button objects:
> 
> 4. Make a new button named "A"
> 
> 5. In the Message Box run:
> 
>   set the behavior of btn "A" to the long id of btn "MyClass"
> 
> 6. Make two copies of btn "A", naming them "B" and "C" respectively.
> 
> 7. Click any of them.
> 
> What you'll see is that each of them uses the script of button "MyClass" as if it's their own, bringing up an answer dialog showing the unique name of each.
> 
> At this point your mind is already thinking of a dozen times in recent projects where you have several objects you wanted to work the same without affecting any other scripts.  We could leave it here and you'd be off writing behaviors very productively right now.
> 
> But we're going to take this one step further - we'll create a superclass:
> 
> 8. Make a new button named "MySuperClass"
> 
> 9. Set this script of that button to:
> 
>   on mouseDown
>      grab me
>   end mouseDown
> 
> 10. In the Message Box run:
> 
>  set the behavior of btn "MyClass" to the long id of btn "MySuperClass"
> 
> 11. Drag any of the "A", "B", or "C" buttons.
> 
> In just 11 steps, each taking only a few seconds, you've just created a rich hierarchy of custom messaging:
> 
>      "A" "B" "C"
>        \  |  /
>         \ | /
>        MyClass
>           |
>           |
>     MySuperClass
> 
> 
> If you wanted the drag behavior used for an entirely different set of objects that do something else on mouseUp, you could make another button named "MyOtherClass" and extend your scope of custom controls even further:
> 
> "A" "B" "C" "D" "E" "F"
>   \  |  /     \  |  /
>    \ | /       \ | /
>   MyClass   MyOtherClass
>       \         /
>        \       /
>       MySuperClass
> 
> Behaviors can be chained as deeply as you like, allowing for very rich class hierarchies.
> 
> This will get you started.  And it only takes a few minutes to explore.
> 
> 
> ------ EXTRA CREDIT -------
> 
> After you feel comfortable with this, an extra credit exercise might be explore overriding and overloading.
> 
> Overriding is blocking an action defined in a parent by using a handler of the same name in a child.
> 
> For example, if you decided button "C" was different from the others and should reports its long ID rather than its name, you could write a script in it with:
> 
>  on mouseUp
>    answer the long id of me
>  end mouseUp
> 
> ...and it'll do that, without affecting any other behaviors provided by the parent script, or affecting any other objects that use the parent script.
> 
> Overloading is augmenting a behavior without replacing it.
> 
> So if you wanted your custom controls (buttons "A", "B", etc.) to be able to have their own mouseUp messages independent of any handling provided in their parent behavior script, you could write the behavior with either of two special forms of message handlers: before or after.
> 
> The script of button "MyClass" could be revised as:
> 
>  after mouseUp
>    answer the name of me
>  end mouseUp
> 
> ...and then the mouseUp message can be handled however you like in any of the class instances ("A", "B", etc.), yet the behavior script will also fire immediately after.
> 
> The "before <message>" works similarly, but as you can guess those fire before the child gets the message.
> 
> Before and after handlers are limited to behavior scripts, as they were added specifically to allow behaviors to augment actions without limiting the scope of normal messages a subscribed object can act on.
> 
> This may be a lot to take in all at once.
> 
> Play with steps 1 to 11 to get going, explore ways to apply that to your work.  Later on you can add "before" and "after" handlers if you need them.  You may not (I rarely use them), but if you do need them they're good to know about.
> 
> Don your pith helmet and begin your adventure!
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> Ambassador at FourthWorld.com                http://www.FourthWorld.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