Musings on Architect, MVC, Nested Behaviors

[Sannyasin Brahmanathaswami]

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