Creates an instance of ProfileManager - Performs basic parameter validation and will create the required profile root directory (if it does not exist) and will attempt to load type configurations from the existing profile root directory (unless the type definitions are passed on the constructor parameters).
See the interface for details.
Parameters passed on the constructor (normally used to create additional instances of profile manager objects)
Load counter for this instance of the imperative profile manager. The load counter ensures that we are not attempting to load circular dependencies by checking if a load (with dependencies) is attempting a load of the same profile twice. The counts are reset when the loads complete, so state should be preserved correctly.
Logger instance - must be log4js compatible. Can be the Imperative logger (normally), but is required for profile manager operation.
Product display name of the CLI.
The profile root directory is normally supplied on an Imperative configuration document, but it is the location where all profile type directories are stored.
The profile "type" for this manager - indicating the profile/schema that this manager is working directly with.
The profile configuration document for the "type" defined to this manager. Contains the schema and dependency specifications for the profile type.
The full set of profile type configurations. The manager needs to ensure that A) the profile type configuration is among the set (because it contains schema and dependency specifications) and B) That other type configurations are available to verify/load dependencies, etc.
The meta file name for this profile type. Of the form "
The root directory for the type (contained within the profile root directory).
The profile schema for the "type". The JSON schema is used to validate any profiles loaded or saved by this profile manager for the type.
The meta file suffix - always appended to the meta file to distinguish from other profiles. Users then cannot supply a profile name that would conflict with the meta file.
The default profile file extension (YAML format) - all profiles are stored in YAML format including the meta profile file.
Accessor that returns a copy of of the profile configuration document.
Accessor for the load counter (protects against circular loading)
Accessor for the logger instance - passed on the constructor
Accessor the input parameters to the constructor - used sometimes to create other instances of profile managers.
Accesor for the product display name.
Accessor for the profile root directory - supplied on the constructor - used to construct the profile type directory.
Accessor for the profile type specified on the constructor.
Accessor for the profile type configuration for this manager.
Accessor for the full set of type configurations - passed on the constructor or obtained from reading the profile root directories and meta files.
Accessor for the profile meta file name - constructed as "
Accessor for the profile type root directory (contained within the profile root directory and named by the type itself)
Accessor for the schema of this type - JSON schema standard
Clears the default profile for the profile managers type.
Reads all configuration documents from the meta and collects all type configuration documents.
Constructs the full path to the profile of the managers "type".
The profile name to construct the path
Builds the meta profile name for this type. Normally of the form "
Create's the directory for this profile manager's type.
Deletes a profile from disk. Ensures that the parameters are correct and removes the profile. If the profile is listed as a dependency of other profiles it will NOT delete the profile unless "rejectIfDependency" is set to false.
See the interface for details
Delete profile - performs the profile delete according to the implementation - invoked when all parameters are valid (according the abstract manager).
See interface for details
Invokes the profile IO method to delete the profile from disk.
The name of the profile to delete.
Construct the default response for the situation when a profile is not found (on a load/save/update/etc), but ignore not found is true.
The name of the profile that was not found
Obtains all profile names for the profile "type" specified on the manager. The names are obtained from the filesystem (in the profile type directory) and the meta file is NOT returned in the list.
Returns the default profile name for this "type" or "undefined" if no default is set.
Checks if the profile (by name) is listed as a dependency of any other profile passed. The type of the profiled named is the type of the current manager object.
The list of profiles to search for the dependency.
Checks if the profile object passed is "empty" - meaning it has no contents other than that type or name. A profile can only specify "dependencies", in the event that it is just acting as a "pointer" to another profile.
The profile to check for "emptiness".
True if the profile object is empty.
Load a profile from disk. Ensures that the parameters are valid and loads the profile specified by name OR the default profile if requested. If load default is requested, any name supplied is ignored.
See the interface for details.
Load all profiles - the behavior is dictated by the implementation.
Load a profiles dependencies - dictacted by the implementation.
the name of the profile to load dependencies for
The profile to load dependencies for.
True to fail "not found" errors
Standard load failed error message and Imperative Error.
The name of the profile for which the load failed.
Save profile - performs the profile load according to the implementation - invoked when all parameters are valid (according the abstract manager).
See interface for details
Loads a specific profile (by name).
The name of the profile to load.
Locate the existing profile for the name specified.
The profile to locate
Merge two profiles together. Useful when updating existing profiles with a few new fields, for example.
the old profile, fields on this will have lower precedence
the new profile, fields on this will have higher precedence
Protects a against an overwrite on a profile save (if requested).
The name of the profile to check for existance.
False to protect against overwrite.
Read the meta profile and validate the contents.
path to the meta profile
Save a profile to disk. Ensures that the profile specified is valid (basic and schema validation) and invokes the implementations "saveProfile" method to perform the save and formulate the response.
See interface for details
Save profile - performs the profile save according to the implementation - invoked when all parameters are valid (according the abstract manager).
See interface for details
Sets the default profile for the profile managers type.
The name of the new default
Set the default profile name in the meta profile for this type.
The meta profile contents.
The name to set as default.
Update the profile - The action performed is dictacted by the implementation of the Abstract manager.
See the interface for details
Update profile - performs the profile update according to the implementation - invoked when all parameters are valid (according the abstract manager).
See interface for details
Validate a profile. Includes basic and schema validation. Can be called explicitly, but is also called during loads and saves to protect the integrity of the profiles against the type definitions.
See the interface for details
Validates the basic configuration document to ensure it contains all the proper fields
The type configuration document
Validate that a meta profile (one read from disk in particular) is valid.
The meta profile to validate
Validate profile - performs the profile validation according to the implementation - invoked when all parameters are valid (according the abstract manager).
See interface for details
Validates the profile against the schema for its type and reports and errors located.
the name of the profile to validate
The profile to validate.
Performs basic validation of a profile object - ensures that all fields are present (if required).
the name of the profile to validate
the type of profile to validate
The profile to validate.
Validates a profiles contents against the required dependencies specified on the profile configuration type document. If the document indicates that a dependency is required and that dependency is missing from the input profile, an error is thrown.
The profile to validate dependency specs
Validate that the schema document passed is well formed for the profile manager usage. Ensures that the schema is not overloading reserved properties.
The schema document to validate.
the type of profile for the schema - defaults to the current type for this manager
Generated using TypeDoc
The abstract profile manager contains most (if not all in some cases) methods to manage Imperative profiles. Profiles are user configuration documents intended to be used on commands, as a convenience, to supply a slew of additional input and configuration (normally more than would be feasible as command arguments). See the "IProfile" interface for a detailed description of profiles, their use case, and examples.
The abstract manager is implemented by (at least as part of Imperative) the BasicProfileManager. The BasicProfileManager implements the save, load, update, etc. methods in, as the name implies, a "basic" way. In general, the abstract manager contains all parameter and profile validation code, methods to write/read/etc and the Basic Manager uses most of the internal methods to perform the "work". The basic manager does in some cases change the default abstract behavior (such as for loadAll profile and loadDependencies).
Imperative, however, uses the the "Cli Profile Manager", which extends the "Basic Profile Manager". The CLI Manager includes additional capabilities, such as creating or updating a profile from command line arguments.
In general, Imperative CLI's will use the "Cli Profile Manager", where the "Basic Profile Manager" is normally sufficient for usage outside of Imperative (for usage in building extensions to editors, Electron apps, programmatic usage of APIs built by implementations of Imperative, etc.), although either can be used.
It is not an absolute requirement, but in the case of an Imperative CLI, the "Basic Profile Manager initialize()" API is invoked to create the required directories and sub-directories. This is NOT a requirement, but avoiding "initialize()" means you must supply all configuration information to the manager when creating an instance. See the "initialize()" API method in the "BasicProfileManager" for full details.