@ -16,43 +16,43 @@ The way I have structured the files and folders in this project remind me of dep
The "Assistants" folder houses the `CoOrdinatorAssistant` and `CommandsAssistant`. These files offer support to their namesake counterparts (in other folders). For example, `CoOrdinatorAssistant` provides "helper" functions for `CoOrdinator` in the "CoOrdinators" folder.
These attributes (files) are what you decorate your command-methods with. If a user decides to use Console.Waterworks' (C.W.) built-in run-time -help system-, these files are what they will end up using. The classes/objects within these files tend to only interact with the `HelpSpecialist`.
To help you get a sense of how to use these files/classes, please use the following links (all found in "As a NuGet" section of this wiki):
* [Overview of Command-Methods](https://git.abbether.net/craig.oates/Console.Waterworks/wikis/Overview-of-Command-Methods)
-With that said, there is nothing stopping you from adding more Co-Ordinator classes in the future. It all depends on how complex the library gets.-
This file connects all the other files together. **This is most critical part of the system**. When you have grasped what is happening in `CoOrdinator`, everything else should start falling into place. `CoOrdinator` connects all the other files together by assigning them tasks. When they have finished their tasks, they return their results to the `CoOrdinator`. From there, `CoOrdinator` will forward the result on to the appropriate class/object. The main idea behind `CoOrdinator` is to limit/control the flow of data in the system. To help explain the above, please read the following page:
This files handles the libraries' constant variables. You have access to `CW-Constants` throughout the codebase but consumers of C.W. do not. Another way look at this file is as the libraries' settings/preferences (as code of course).
@ -60,7 +60,7 @@ This files handles the libraries' constant variables. You have access to `CW-Con
Its main purpose is to document the flow of C.W. I tend to use it for testing purposes most of the time. An important note to make is none of the logging events will show in projects which -consume- this library (as a NuGet package). Also, I tend to control the `CW-Logger`via `CoOrdinator`, for the most part. You are not limited to using `CW-Logger` that way, though. If you want, you can call/control is at any point throughout the system.
@ -70,7 +70,7 @@ Its main purpose is to document the flow of C.W. I tend to use it for testing pu
This file is responsible for how the command-method must look -- from the (console) end-user and (developer) consumer. Altering this file will affect the way the end-user will enter commands into the console and how you construct them. Because of that, be careful when/if you make changes to this file.
@ -78,17 +78,17 @@ This file is responsible for how the command-method must look -- from the (conso
This folder houses the most files and is where you will spend most of your time. The files in here are where the `CoOrdinator` hands most of its tasks off to. The list of files in this folder are as follows:
As their names imply, each file/class specialises in one area and does not venture outside of it. The idea here is `CoOrdinator` hands work over to the appropriate specialist. When the specialist finishes its task, it returns its result back to `CoOrdinator`. This makes it easy (easier?) to create conveyor-belt-like work/dataflows in the system. I, also, find it easier to narrow down any problems -- let's hope you do too.
The `CoercionSpecialist` handles the coercing of the end-user's input into a data type C# understands. There is a limit on the amount of data types Console.Waterworks works with. So, make sure you familiarise yourself with them. A complete list of the types C.W. can coerce is available at the following link:
