Howto:Using Driver Hashes in Nasal

This article is a stub. You can help the wiki by expanding it.

Objective

Demonstrate how to put context specific functionality (APIs) into so called driver hashes to easily switch between different front-ends or back-ends respectively.

What is a driver hash

It's a conventional Nasal hash (imagine it like a namespace), which typically contains callbacks, i.e. functions. Driver hashes are usually nested in an outer hash, where a key can be used to look up the concrete implementation.

This is an empty hash named myDriverHash:

var myDriverHash = {
};

To populate the hash, we need to add keys to it - in this case, this can be best accomplisheed by adding strings to it, with a color specifying the value:

var myDriverHash = {

"key1": "value"

};

Different key/value pairs are separated using a comma:

var myDriverHash = {

"key1": "some value",
"key2": "another value",

};

Problem

We have an increasing number of similar features that are sometimes even mutually incompatible, often this applies to features for which different alternatives/approaches exist, for example:

• JSBSim vs. YASim
• Basic Weather vs. Advanced Weather
• Rembrandt vs. ALS
• Phi vs. PUI
• osgEarth vs. the standard scenery engine

...

However, Nasal scripts may need to work with all of these components, regardless of the concrete implementation - this is where we commonly see spaghetti code using lots of nested if/elseif constructs to deal with the differences among these implementations.

Example

Let's imagine, we have a piece of Nasal code that needs to work with different FDMs (or autopilot/route manager configurations).

The YASim property may be named

Related

References