Can use assign multiple behaviors to a single object?
brahma at hindu.org
Thu Aug 11 22:22:56 EDT 2016
Sure, I think we would be interested.
Not sure if the above qualifies as use case… but may help ?
Our new app is very modular. Layout on disk looks like this
# stack script initializes all back/front and lib required to app wide use
# as declared in the json file.
/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
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
dev 2 is building
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
/[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.
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.
More information about the Use-livecode