From 4e0e32f76ea7a42b473df028aa8224b39b5d7bad Mon Sep 17 00:00:00 2001 From: Jason T Alborough Date: Fri, 21 Feb 2020 17:52:06 -0500 Subject: [PATCH 1/3] Removes the references to bugfix/ in git flow section --- Home.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Home.md b/Home.md index 51ea18f..ebd3c50 100644 --- a/Home.md +++ b/Home.md @@ -53,8 +53,8 @@ The `master` branch always contain the latest stable version. The `development` [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/) will be used as the workflow for this collaborative project. To contribute, follow this process: 1. Fork this repository -2. Create a branch using standard GitFlow branch prefixes (feature/hotfix/bugfix) followed by a descriptive name. - - Example: `feature/add-awesomeness`,`bugfix/wow-im-dumb` or `hotfix/really-big-oops` +2. Create a branch using standard GitFlow branch prefixes (feature/hotfix) followed by a descriptive name. + - Example: `feature/add-awesomeness` or `hotfix/really-big-oops` - When working on a new feature or bugfix, branch from the `development` branch. When working on a hotfix, branch from `master`. 3. Make commits as necessary (often is better). And use concise, descriptive language, leveraging issue notation and/or [Closing Keywords](https://help.github.com/articles/closing-issues-using-keywords) to ensure any issues addressed by your work are referenced accordingly. 4. When the scope of the work for your branch is complete, make sure to rebase your branch in case further progress has been made since the repo was forked From 20f4b8986b9bebfb3005390c0fa89f61dc692661 Mon Sep 17 00:00:00 2001 From: Jason T Alborough Date: Fri, 21 Feb 2020 18:11:50 -0500 Subject: [PATCH 2/3] Removes the json tag from the code blocks in the Configuration. It was causing the comments to render weird because comments are not legal in json. --- ConfigurationStructure.md | 14 +++++++------- Plugins.md | 2 +- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/ConfigurationStructure.md b/ConfigurationStructure.md index 8a5cef7..2993fef 100644 --- a/ConfigurationStructure.md +++ b/ConfigurationStructure.md @@ -8,7 +8,7 @@ At a high level, the idea is to define a template of all of the common configura ## Top Level Object Structure (Double Config) -``` json +``` { // This object is deserialized to type PepperDash.Essentials.Core.Config.EssentialsConfig @@ -64,7 +64,7 @@ The idea being that configuration values that are common to all systems can be s Below is an example of a double configuration containing both template and system properties. -``` json +``` { "template": { "info": { @@ -93,7 +93,7 @@ Below is an example of a double configuration containing both template and syste } ``` Below is an example of the result of merging the above double configuration example into a single configuration. -``` json +``` { "info": { "name": "System Name", // Since this property existed in both the template and system, the system value replaces the template value after the merge @@ -111,7 +111,7 @@ Below is an example of the result of merging the above double configuration exam --- ## Device Object Structure The devices array is meant to hold a series of device objects.  The basic device object structure is defined below. -``` json +``` { "key": "someUniqueString", // *required* a unique string "name": "A friendly Name", // *required* a friendly name meant for display to users @@ -147,7 +147,7 @@ Some additional details about specific properties that are important to note: ## The Device Properties.Control Object The control object inside properties has some reserved properties that are used by configuration tools and Essentials that require some caution. -``` json +``` { "properties": { // *required* an object where the configurable properties of the device are contained "control": { // an object to contain all of the properties to connect to and control the device @@ -183,7 +183,7 @@ The control object inside properties has some reserved properties that are used ## Device Merging The following examples illustrate how the device key and uid properties affect how devices are merged together in a double configuration scenario.  In order for a template device and a system device to merge, they must have the same key and uid values -``` json +``` { "template": { "info": { @@ -239,7 +239,7 @@ The following examples illustrate how the device key and uid properties affect h } ``` Below is an example of the result of merging the above double configuration example into a single configuration.   -``` json +``` { "info": { "name": "System Name", diff --git a/Plugins.md b/Plugins.md index ee061a8..32bba3f 100644 --- a/Plugins.md +++ b/Plugins.md @@ -21,7 +21,7 @@ One or more plugins can be loaded to the /user/ProgramX/plugins as .dlls or .cpl All plugin assemblies must contain a static method called LoadPlugin(): ```csharp -public class SomeDevice : Device , IBridge //IBridge only needs to be implemented if +public class SomeDevice : Device , IBridge //IBridge only needs to be implemented if using a bridge { // This string is used to define the minimum version of the // Essentials Framework required for this plugin From aa053d633ae4b94db5ad1ffd6005428476b07be6 Mon Sep 17 00:00:00 2001 From: Jason T Alborough Date: Fri, 21 Feb 2020 18:17:06 -0500 Subject: [PATCH 3/3] Small fix to code bloc in Debugging.md --- Debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Debugging.md b/Debugging.md index 7652930..7f59617 100644 --- a/Debugging.md +++ b/Debugging.md @@ -48,7 +48,7 @@ Debug.Console(0, "Hello {0}", world); // This overload takes an IKeyed as the second parameter and the resulting statement will // print the Key of the device in console to help identify the class instance the message // originated from -Debug.Console(0, this, "Hello World); +Debug.Console(0, this, "Hello World"); // prints: [timestamp]App 1:[deviceKey]Hello World // Each of the above overloads has a corresponding variant that takes an argument to indicate