Can use assign multiple behaviors to a single object?

[Sannyasin Brahmanathaswami]

@Dick

Sure, I think we would be interested. 

@ monte

Not sure if the above qualifies as use case… but may help ?

Our new app is very modular. Layout on disk looks like this

config.json
loader stack 
    # stack script initializes all back/front and lib required to app wide use
    # as declared in the json file.
   /modules
       /home
              config.json
              home.livecode
       /module 2
              config.json
              module 2.livecode
       /module 3
              config.json
              module 3.livecode
       /module 4
              config.json
              module 3.livecode
       /module 3
              config.json
              module 2.livecode
  /shared
      /backscripts # all instantiated at start up
             /api.livecode # app wide but not too long, no meant to overload.
      /frontscripts # all instantiated at start up
      /libs # meant to be instantiated with "start/stop using"

The loader stack initializes all back and front scripts, reads the top config.json and sees that the launchModule should be "home.livecode"  and that's what appear on screen on mobile at boot.  this is working great.  but obviously could get crazy very fast with library bloat.

user could later make module3 their opening modules, and the app will write that "favorite" request to the top config.json… next time they reboot the app on the phone, it would open to module3.livecode. 

So that's the architecture. 

OK so now the subjective views of life arrive.

For creating scrollers, which would be  "universal" requirement across the entire app, one approach is to create simply add another lib or backscript, include this in the json (which lists all libs to be initialized on start up) and it is loaded into the msg path on start up. 

The other approach would be to create a behavior and attach that to every stack that needs scrollers. 

Frankly, despite the "geeky, cool" appearance of nested behaviors, in this scenario I'm not seen that many advantages. I just like to explore it to see if new visions may actually be more maintainable, less buggy in the long run.

 But another view of life says that behaviors really REALLY, should only be used when there is  a very unique set of vars/methods that apply to (in this case) one card on one module.livecode stack.

Despite the attractiveness of Richard Parent/Child = a "kinda class like object hierarchy" I'm not seeing that it gets us anything more than backscripts if there is at all any commonality of methods that might be re-used on modules across the entire app. If you have 4 developers working on 

module1.livecode
module2.livecode
module3.livecode
module4.livecode

you just have to tell everyone to stay away form the loader and the api backscript, and be sure to pull every day and push every day (we are using Git) there is a bit of "pass the baton" that needs to be played by telling everyone to be careful, but since the config.json files and backscripts are all text…merging is not a problem. 

Meanwhile if dev 1 is building
modules1
      /image-puzzles.livecode
and
dev 2 is building
modules2
    /interactive-books.livecode

we know that binary and the files in that modules folder are "none of our business" and there are no merge issues.

BUT were we start mixing a complex chain of parent-child behaviors into this overall CMS… I think it would become a team nightmare.   Also the requirement to attach behaviors when other wise you could just call a command you know is in the message path?

That said if dev2 wants to do that in his sand box

modules2
    /interactive-books.livecode 
            /books-shared
              /[100 small behaviors]

 fine… go ahead… no problem. 

There is also the issue of dealing with different opinions on the team as to the best architecture.  It's a different working environment than one dev building product working in a silo all by himself.

As an admin "sweet boss" I have a simple way to handle that: most senior on the team + most work out the door in the past two years in terms of  product(s) produced his or her opinion trumps "cool innovation" that actually has never used in production for anything that is actually in the app store. 

BR




        
      




On 8/11/16, 2:17 PM, "use-livecode on behalf of Dick Kriesel" <use-livecode-bounces at lists.runrev.com on behalf of dick.kriesel at mail.com> wrote:

    Because multiple behaviors appear in a list whose sequence the developer controls, the message path stays deterministic.