Script Only Stack Architecture

[Richard Gaskin]

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