# Module: warden

Contains all the functions to manage the entire application framework at the highest level. Also provides an interface to easily manage all the framework features & various functionality from a single entry point.

Author:
  - Seth Hollingsead
Copyright:
  - Copyright © 2022-… by Seth Hollingsead. All rights reserved
Source:
  - controllers/warden.js, line 1

### Requires

- module:dataBroker
- module:ruleBroker
- module:chiefCommander
- module:chiefConfiguration
- module:chiefData
- module:chiefPlugin
- module:chiefTheme
- module:chiefWorkflow
- module:configurator
- module:loggers
- module:stack
- @haystacks/constants
- path

### Methods

#### (inner) clearAllPluginRegistry() → {boolean}

This is a wrapper function for chiefPlugin.clearPluginRegistry. Which is in-turn a wrapper function for pluginBroker.unregisterAllPlugins.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 577

##### Returns:

True or False to indicate if the plugin registry data hive was cleared successfully or not.

Type
  boolean

#### (inner) consoleLog(classPath, message) → {void}

This is just a wrapper for the loggers.consoleLog function.

##### Parameters:

Name | Type | Description
--- | --- | ---
`classPath` | string | The class path fro the caller of this function file.function or class.method.
`message` | string | boolean | integer | object | The message or data content that should be dumped to the output.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 967

##### Returns:

Type
  void

#### (inner) enqueueCommand(command) → {void}

Adds a command to the command queue. It is worth noting that a command could actually load a whole workflow of commands. So one command can spawn into many commands that cause the command queue to be very full with a very complicated workflow. This also acts as a wrapper for the chiefCommander.enqueueCommand function.

##### Parameters:

Name | Type | Description
--- | --- | ---
`command` | string | The command to add to the command queue for executing.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 854

##### Returns:

Type
  void

#### (inner) executeBusinessRules(inputs, businessRules) → {string}

A wrapper to call a business rule from the application level code.

##### Parameters:

Name | Type | Description
--- | --- | ---
`inputs` | array.<(string|integer|boolean|object|function()), (string|integer|boolean|object|function())> | The array of inputs: inputs[0] = inputData - The input to the rule that is being called. inputs[1] = inputMetaData - Additional data the input to the rule.
`businessRules` | array.<string> | The array that contains the name(s) of the business rule that should be executed.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 829

##### Returns:

The value that is returned from the rule is also returned.

Type
  string

#### (inner) getConfigurationSetting(configurationNamespace, configurationName) → {string|integer|boolean|double}

This is just a wrapper for the configurator getConfigurationSetting function.

##### Parameters:

Name | Type | Description
--- | --- | ---
`configurationNamespace` | string | The path in the configuration JSON object where the configuration setting should be found.
`configurationName` | string | The key of the configuration setting.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 942

##### Returns:

The value of whatever was stored in the D[configuration].

Type
  string | integer | boolean | double

#### (inner) getPluginsRegistryPath() → {string}

This is a wrapper function for the chiefPlugin.getPluginsRegistryPath. Which is in-turn a wrapper function for pluginBroker.getPluginsRegistryPath.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 771

##### Returns:

The path to the plugins listed in the plugin registry as meta-data.

Type
  string

#### (inner) initFrameworkSchema(configData) → {void}

Setup all the framework data and configuration settings.

##### Parameters:

Name | Type | Description
--- | --- | ---
`configData` | object | All of the configuration data that should be parsed as part of the setup process.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 75

##### Returns:

Type
  void

#### (inner) isCommandQueueEmpty() → {boolean}

This is a wrapper for the chiefCommander.isCommandQueueEmpty function. Determines if the command queue is empty or not, which also determines if the application should continue executing commands from the command queue in sequential order or prompt for another command or exit.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 875

##### Returns:

True or False to indicate if command execution should continue or not.

Type
  boolean

#### (inner) listAllPluginsInRegistry() → {array.<string>}

This is a wrapper function for chiefPlugin.getAllPluginsInRegistry. Which is in-turn a wrapper function for pluginBroker.listPluginsInRegistry.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 416

##### Returns:

A list array of the names of the plugins in the plugin registry.

Type
  array.<string>

#### (inner) listAllPluginsInRegistryPath() → {array.<string>}

This is a wrapper function for chiefPlugin.getAllPluginsInRegistryPath. Which is in-turn a wrapper function for pluginBroker.listPluginsInRegistryPath.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 434

##### Returns:

A list array of the names of the plugins in the plugin registry.

Type
  array.<string>

#### (inner) listLoadedPlugins() → {array.<string>}

This is a wrapper function for chiefPlugin.listLoadedPlugins. Which is in-turn a wrapper function for pluginBroker.listAllLoadedPlugins.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 398

##### Returns:

A list array of the names of the plugins that are currently loaded.

Type
  array.<string>

#### (inner) loadCommandAliases(commandAliasesPath) → {void}

Loads and merges both the system defined command aliases XML file and the client defined command aliases XML file, or an optional user defined command aliases path.

##### Parameters:

Name | Type | Description
--- | --- | ---
`commandAliasesPath` | string | The configuration name of the configuration setting where the path to the commands aliases XML file is stored, that should be loaded (OPTIONAL).

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 325

##### Returns:

Type
  void

#### (inner) loadCommandWorkflows(workflowPathConfigName) → {void}

Loads and merges both the system defined command workflows XML file and client defined command workflows XML file, or an optional user defined workflow path.

##### Parameters:

Name | Type | Description
--- | --- | ---
`workflowPathConfigName` | string | The configuration name of the configuration setting where the path to the workflows XML file is stored, that should be loaded (OPTIONAL).

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 362

##### Returns:

Type
  void

#### (inner) loadPlugin(pluginPath) → {boolean}

Calls the plugin initializePlugin function to get the plugin data: Business rules, Commands, Workflows, Constants, Configurations, dependencies ist (dependant plugins), etc...

##### Parameters:

Name | Type | Description
--- | --- | ---
`pluginPath` | string | The fully qualified path where to load the plugin from, or the folder name that will contain the plugin in the plugin registry path.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 613

##### Returns:

True or False to indicate if the plugin was loaded successfully or not.

Type
  boolean

#### (inner) loadPluginResourceData(contextName, pluginResourcePath) → {object}

Calls the necessary functions to load and parse the resource data from the specified path.

##### Parameters:

Name | Type | Description
--- | --- | ---
`contextName` | string | The type of resource that is being loaded, eg: configuration, commandAliases, workflows, ect...
`pluginResourcePath` | string | The fully qualified path to the plugin resource data.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 789

##### Returns:

The JSON data that is loaded and parsed from the plugin path.

Type
  object

#### (inner) loadPlugins(pluginsPaths) → {boolean}

Calls the plugin initializePlugin function to get the plugin data, for each of the plugins in the input array of plugin paths: Business rules, Commands, Workflows, Constants, Configurations, dependencies list (dependant plugins), etc...

##### Parameters:

Name | Type | Description
--- | --- | ---
`pluginsPaths` | array.<string> | An array of fully qualified paths where to load the plugins from.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 637

##### Returns:

True or False to indicate if all the plugins were loaded or not.

Type
  boolean

#### (inner) loadPluginsFromRegistry() → {boolean}

Calls the plugin initializePlugin function to get teh plugin data, for each of the plugins and their paths from the plugin registry. Business rules, Commands, Workflows, Constants, Configurations, dependencies list (dependant plugins), etc...

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 669

##### Returns:

True or False to ndicate if all the plugins were loaded or not.

Type
  boolean

#### (inner) mergeClientBusinessRules(clientBusinessRules) → {void}

Merges the map of client defined business rule names and client defined business rule function calls with the existing D-data structure that should already have all of the system defined business rule.

##### Parameters:

Name | Type | Description
--- | --- | ---
`clientBusinessRules` | object | A map of client defined business rule names and client defined business rule function calls.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 291

##### Returns:

Type
  void

#### (inner) mergeClientCommands(clientCommands) → {void}

Merges the map of client defined command names and client defined command function calls with the existing D-data structure that should already have all of the system defined commands.

##### Parameters:

Name | Type | Description
--- | --- | ---
`clientCommands` | object | A map of client defined command names and client defined command function calls.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 308

##### Returns:

Type
  void

#### (inner) numberOfPluginsInRegistry() → {integer}

This is a wrapper function for chiefPlugin.countAllPluginsInRegistry. Which is in-turn a wrapper function for pluginBroker.countPluginsInRegistry.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 452

##### Returns:

The count of the number of plugins listed in the plugin registry data hive.

Type
  integer

#### (inner) numberOfPluginsInRegistryPath() → {integer}

This is a wrapper function for chiefPlugin.countAllPluginsInRegistryPath. Which is in-turn a wrapper function for pluginBroker.countPluginsInRegistryPath.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 470

##### Returns:

The count of the number of plugin sub-folders in the plugins path listed in the plugin registry data hive.

Type
  integer

#### (inner) processCommandQueue() → {array.<boolean, (string|integer|boolean|object|array)>}

This is just a wrapper for the chiefCommander.processCommandQueue function, which will ultimately call chiefCommander.processCommand to process an individual command. This is because a command could actually invoke a command workflow that might enqueue a bunch of commands to the command queue. All of them must be executed in sequence as part of the main application loop.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 895

##### Returns:

An array with a boolean True or False value to indicate if the application should exit or not exit, followed by the command output.

Type
  array.<boolean, (string|integer|boolean|object|array)>

#### (inner) processRootPath(inputPath, actualFrameworkName) → {string}

Processes the root path of the application using business rules.

##### Parameters:

Name | Type | Description
--- | --- | ---
`inputPath` | string | The path for the entry point to the framework, ie: main.js
`actualFrameworkName` | string | The name of the framework that the application is expecting to use.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 47

##### Returns:

the true root path of the application.

Type
  string

#### (inner) registerPluginByNameAndPath(pluginName, pluginPath) → {boolean}

This is a wrapper function for chiefPlugin.registerNamedPlugin. Which is in-turn a wrapper function for pluginBroker.registerPlugin.

##### Parameters:

Name | Type | Description
--- | --- | ---
`pluginName` | string | The name of the plugin that should be registered.
`pluginPath` | string | The path to the plugin, to be added to the plugin registry. This should be the path to the plugin/package.json file, but not including the package.json as part of the path URI.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 488

##### Returns:

True or False to indicate if the plugin was added to the plugin registry successfully or not.

Type
  boolean

#### (inner) resetRulesAndCommands() → {void}

Clears and then re-initializes the Haystacks platform framework business rules and commands. This is needed because: When Haystacks is used to load plugins, the plugin needs to make a call back to Haystacks to load all the plugin resource non-code files. When the plugin does that it is creating a new instance of Haystacks. The new instance of Haystacks created by the plugin is not the same instance as the original instance of Haystacks. We get around that by injecting all of the data from the original Haystacks into the new plugin-instance of Haystacks. However, when trying to call the business rules or commands using the dependency injected data, the business rules are not found, and cannot be executed. It turns out because the paths are completely different. The original instance of Haystacks initialized all its business rules and commands from the original instance path. So when executing those business rules and those commands it executes that code from those files using that path. However, when trying to pump those same business rules and commands into the plugin instance and then execute the same code, the plugin instance doesn't have access to or know about the paths to those business rules or commands. So therefore the solution is to have the plugin instance of Haystacks to clear and re-initialize its own business rules and commands. That way the plugin instance of Haystacks, when it tries to execute its own business rules and commands it will be doing so using, its own path to those business rules and commands and should therefore work as expected.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 263

##### Returns:

Type
  void

#### (inner) setConfigurationSetting(configurationNamespace, configurationName, configurationValue) → {void}

This is just a wrapper for the configurator setConfigurationSetting function.

##### Parameters:

Name | Type | Description
--- | --- | ---
`configurationNamespace` | string | The path in the configuration JSON object where the configuration setting should be set. Ex: businessRules.rules.stringParsing.countCamelCaseWords
`configurationName` | string | The key of the configuration setting.
`configurationValue` | string | integer | boolean | double | The value of the configuration setting.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 916

##### Returns:

Type
  void

#### (inner) syncPluginRegistryWithPath() → {boolean}

This is a wrapper function for chiefPlugin.synchronizePluginRegistryWithPath Which is in-turn a wrapper function for pluginBroker.synchPluginRegistryWithPluginRegistryPath.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 555

##### Returns:

True or False to indicate if the synchronization was performed successfully or not.

Type
  boolean

#### (inner) unloadAllPlugins() → {boolean}

Calls various functions in the chiefPlugin and pluginBroker to unload and remove all plugin metaData and data: Business rules, Commands, Workflows, Constants, Configurations, dependencies ist (dependant plugins), etc...

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 752

##### Returns:

True or False to indicate if all the plugins were unloaded successfully or not.

Type
  boolean

#### (inner) unloadPlugin(pluginName) → {boolean}

Calls various functions in the chiefPlugin and pluginBroker to unload and remove all plugin metaData and data for the specified plugin: Business rules, Commands, Workflows, Constants, Configurations, dependencies list (dependant plugins), etc...

##### Parameters:

Name | Type | Description
--- | --- | ---
`pluginName` | string | The name of the plugin that should be unloaded.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 690

##### Returns:

True or False to indicate if the plugin was unloaded successfully or not.

Type
  boolean

#### (inner) unloadPlugins(pluginNames) → {boolean}

Calls various functions n the chiefPlugin and pluginBroker to unload and remove all the metaData and data for a list of plugins: Business rules, Commands, Workflows, Constants, Configurations, dependencies list (dependant plugins), etc...

##### Parameters:

Name | Type | Description
--- | --- | ---
`pluginNames` | array.<string> | An array ist of names of plugins that should be unloaded.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 715

##### Returns:

True or False to indicate if all the plugins were unloaded successfully or not.

Type
  boolean

#### (inner) unregisterPluginByName(pluginName) → {boolean}

This is a wrapper function for chiefPlugin.unregisterNamedPlugin. Which is in-turn a wrapper function for pluginBroker.unregisterPlugin.

##### Parameters:

Name | Type | Description
--- | --- | ---
`pluginName` | string | The name of the plugin that should be removed from the plugin registry.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 513

##### Returns:

True or False to indicate if the plugin was removed from the plugin registry successfully or not.

Type
  boolean

#### (inner) unregisterPlugins(pluginsListArray) → {boolean}

This is a wrapper function for chiefPlugin.unregisterPlugins. Which is in-turn a wrapper function for pluginBroker.unregisterPlugins.

##### Parameters:

Name | Type | Description
--- | --- | ---
`pluginsListArray` | array.<string> | A list array of plugin names that should be removed from the plugin registry.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 534

##### Returns:

True or False to indicate if all the plugins were successfully removed from the plugin registry or not.

Type
  boolean

#### (inner) writePluginRegistryToDisk() → {boolean}

This is a wrapper function for chiefPlugin.savePluginRegistryDisk. Which is in-turn a wrapper function for pluginBroker.savePluginRegistry.

Author:
  - Seth Hollingsead
Source:
  - controllers/warden.js, line 595

##### Returns:

True or False to indicate if the plugin registry was successfully saved to the disk or not.

Type
  boolean