Calling methods from Sibling Components

[pturmel]

@PGriffith

cleanly versionable and maintainable

Yes, the main driver. Keeping python in resource files that are cleanly identifiable as python by external tool in source code control is part of that motivation.

@PGriffith

would you still advocate pushing all logic into the project library?

Yes.

@PGriffith

going all the way out to the project library

?

What do you mean by "all the way out" ? Library scripts are easily floated to be accessible while working on UI components and all kinds of gateway resources. Total win. And even if not floated, the script editors help you pick the function you need.

@PGriffith

nicer editing experience

Oy! The designer's plethora of event resource dialogs are not "nice", IMNSHO.

And further, the business/presentation boundary, in a well-organized gateway, is managed with inheritance, like the hierarchy I recommend over here:

Where do/should Gateway Scripts live with respect to an inherited project structure?

Put all of the logic in project library scripts, in the "universe" project at the root of your hierarchy, if you must. Then, in leaf projects, use one-line calls to the appropriate logic from event scripts and message handlers. (I don't agree with your desire, but this is what you must do to achieve it.) I recommend you not put all your scripts (eggs) in one inheritable project (basket). I recommend a hierarchy something like this: universe ├bg_common │├gsp │├background1 │├background2 │└we…

Well tested business logic, that is not context-specific, belongs in that "universe" project. Shared presentation logic belongs in "ui_common", "perspective_common", or "vision_common". Project-specific presentation logic stays at the leaf, but in a project library script, to cover its possible future promotion to a shared resource.