Well, this stimulated a quite a discussion.
@Trevor: Thank you about tips on staying organized. An very good points on how
useful it could be the have nested behaviors though you have not used it yet
this was an important observation :" If you use a library script you have to
pass a
model instance identifier to every handler in the library. Using a behavior
script attached to a card could remove that need as each behavior has it's
own instance of the script local variables used in the model behavior
script. The approach could also simplify callbacks because the target would
always be the object the model behavior is attached to." Wow...
BUT: " A new developer may be more likely to see the chained behavior if the
behaviors are explicitly assigned in code vs having to use vs going to the IDE
to look up what the behavior chain is."
That is a problem using "Navigator" (does not show nested behaviors) or the
Project Browser which simply as (2)(1)(5) too obscure....
" if the behaviors are explicitly assigned in code"
How would you do that? Currently it is obfuscated from the developer by the
IDE
" script "behavior_MyAudio" with behavior "behavior_ListenUI"
Does not appear in the Script Editor. I consider that a "deficit" attribute of
the "whole system" of nested behaviors.
I put comments at the top of my "child" behavior, so that it appears the SE.
//> This script has a parent behavior
//> behavior_ListenUI
@ Richard "Or maybe I misunderstand. Is the issue with script-only stacks, or
with
deeply-nested parentScript chains?"
The "scary" thing about the original project, ( that Jacqueline referred to)
was code,( not written by me or anyone here), that used Get and Set properties
that sometimes went through four-five libraries before they "resolved
themselves" to get what the calling function "wanted" and when one function
call to a library would have done the same. Or to use, Jacque MO, to one huge
stack script. It was not about script-only and deeply nested-parentScript
chain.
@ Jacqueline: I have refactored 95% of the code that drove us nuts before. Now
debugging that is to 1- 3 libraries at the most. There are many libraries, but
discovering "what is wrong" will take to you one or two at the most, "whew!"
-- GIT has been indispensable, not only for collaboration, but the way it
handles branches, being about to fetch revisions.
@ Bob S. Very good and useful examples (dategrid) of how and why to use nested
behaviors. I think my query was too generalized, like everything else "depends
what you are trying to do"
@at all -- Andre's "aagNetTracer" is the "bomb" for debugging, on the desk top
and on the phone. He has "leaped frogged" far beyond the whole issue of
breakpoint in code.
@ y'all about revision control of binary stacks and YAML properities (front
matter) for text only scripts.. cool musings! but they might want/need
different threads?
BR
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
