Howto:Using Driver Hashes in Nasal: Difference between revisions
Jump to navigation
Jump to search
Line 12: | Line 12: | ||
* Rembrandt vs. ALS | * Rembrandt vs. ALS | ||
* [[Phi]] vs. [[PUI]] | * [[Phi]] vs. [[PUI]] | ||
... | |||
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 == | == Background == |
Revision as of 19:23, 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.
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
|