Howto:Using Driver Hashes in Nasal: Difference between revisions
Line 3: | Line 3: | ||
== Objective == | == 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. | 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. | |||
== Problem == | == Problem == |
Revision as of 19:24, 14 October 2017
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.
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:
...
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.
Background
Related
References
|