i still can't figure out what's the best way to achieve it. An example: many MapStructure layers i created for the Airbus ND differs from the ones used by the Boeing ND, and it's not just a matter of graphics, but sometimes they also have different logics, so different code for Symbols and maybe for Layer Controllers too.
In such cases, it makes sense to use "styling" support for colors, fonts, symbols etc - and if something contains custom logic, just allow the corresponding logic to be overridden by using an optional callback that defaults to
nil and which is only used if typeof(callback)=='func'. However, in general, it does make sense to use separate controllers for now - Philosopher once mentioned that he was contemplating to generalize the frameworks so that we could reuse draw/symbol routines with different controllers and vice versa - but maybe we shouldn't skip too many iterations currently, and just let things evolve naturally, i.e. step-by-step.
For that, I'd suggest to use 1) separate controllers, 2) styling hashes (df_style), 3) customizable logic via optional callbacks
Likewise, there are some other things that should ideally be configurable, such as hard-coded properties like nav[x] - those could/should use the same method for making properties OPTIONALLY configurable.
So, for example, the RTE layer in the airbus can use dashed or solid lines, or different colors depending on the fact that the flight plan is active or that horizontal mode is "managed" (Boeing LNAV).
The VOR Symbol has different graphics from the Boeing one, and changes color depending on the fact that it's tuned or not.
that's the kind of stuff that should be addressed via styling, grep for "df_style" to learn how it's done currently, I think the VOR/DME files contain a few examples.
In general, we're hoping to move styling out of the lcontroller files into the symbol files using the style, though.
aircraft-specific "behavior" would best be implemented as is, but customizable via callbacks.
So, if we want to move all this stuff outside the aircraft (into the FGData canvas/map directory), what's the best way the create aircraft-agnostic code at this point?
Anything that is aircraft specific should be passed to the controller, i.e. at initialization/ctor time via the new() flag - alternatively, use a separate .setBehavior() method that accepts a hash with callbacks supported by your lcontroller/symbol files. You can look at how styling is implemented, it basically works at layer creation time (see api.nas and .addLayer() there) - from then on, it's passed down to the corresponding ctor.
The whole idea is to introduce/support a custom hash and support optional fields in there, that may contain callbacks for keeping "delegates" that can be provided by some external front-end, such as for example your aircraft. I think you only need to look at how styling support is implemented, to see that you can use the same method for also passing callbacks around to move aircraft-specific logic out of the MapStructure layers.