@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"
<[email protected] on behalf of [email protected]>
wrote:
Because multiple behaviors appear in a list whose sequence the developer
controls, the message path stays deterministic.
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
