@ -21,5 +21,5 @@ For C.W. to operate as designed, it needs to rely on certain things, which are;
If you are new to the project, I recommend you take a moment to look at the code in "Program.cs" and "ConsoleCommand.cs". Once you have a good grasp of what it happening in "Program.cs", you should not need to look at it again. That is when you can start to focus on the code in "ConsoleCommands.cs" -- the place where most of the work is. The links for these files are as follows:
* [CW_Console.csproj](https://gitlab.com/craig.oates/Console.Waterworks/blob/master/Console.Waterworks/CW_Console/CW_Console.csproj) (the ".csproj" bit is the standard part)
* [AssemblyInfo.cs](https://gitlab.com/craig.oates/Console.Waterworks/blob/master/Console.Waterworks/CW_Console/Properties/AssemblyInfo.cs) (residing in the "Properties" folder)
* [CW_Console.csproj](https://git.abbether.net/craig.oates/Console.Waterworks/blob/master/Console.Waterworks/CW_Console/CW_Console.csproj) (the ".csproj" bit is the standard part)
* [AssemblyInfo.cs](https://git.abbether.net/craig.oates/Console.Waterworks/blob/master/Console.Waterworks/CW_Console/Properties/AssemblyInfo.cs) (residing in the "Properties" folder)
With these files being standard files, in a typical C# project, I will not spend any time of them. What I will do instead is focus on the project specific files. If you are more interested with jumping straight into the code, start at "Program.cs". then move onto "ConsoleCommands.cs".
@ -4,9 +4,9 @@ This is a traditional .Net 4.7 library, written in C#. Its main purpose is to ho
Within the project, you will see four files and a folder. Of the four files, you will spend most of your time in one which is called "CW_ConsoleTest.cs"; This is where the tests are. The remaining files are standard Visual Studio (C#) project files. Links to the above files are as follows:
* [AssemblyInfo.cs](https://gitlab.com/craig.oates/Console.Waterworks/blob/master/Console.Waterworks/CW_Tests/Properties/AssemblyInfo.cs) (in the "Properties" folder)
* [AssemblyInfo.cs](https://git.abbether.net/craig.oates/Console.Waterworks/blob/master/Console.Waterworks/CW_Tests/Properties/AssemblyInfo.cs) (in the "Properties" folder)
If you are unsure what the methods in `CW_Liaison` do, use Visual Studio's intellisense. You can, also, read the code in `CW_Liaison` with the following link:
Before going into further detail... If you want to jump straight into the code, [CW_Liaison.cs](https://gitlab.com/craig.oates/Console.Waterworks/blob/master/Console.Waterworks/Console.Waterworks/CW_Liaison.cs) is the place to start. It is the entry point to the library when using it in a project.
Before going into further detail... If you want to jump straight into the code, [CW_Liaison.cs](https://git.abbether.net/craig.oates/Console.Waterworks/blob/master/Console.Waterworks/Console.Waterworks/CW_Liaison.cs) is the place to start. It is the entry point to the library when using it in a project.
"Console.Waterworks.csproj" is a typical C# project file -- found with all Visual Studio projects. So, you should not need to touch it and the reason why I will not focus on it. The same applies to "Assemblyinfo.cs" which resides in "Properties".
@ -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://gitlab.com/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 @@ _The point about adding more `Co-Ordinator` classes (Loggers in this case) to th
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:
Welcome to the wiki of Console.Waterworks. The aim of this wiki is to show you how Console.Waterworks works and how it is built. Feel free to use the sidebar, on the right, to navigate around the wiki.
@ -27,11 +27,11 @@ Before continuing, I recommend you are familiar with the following:
I have made a .Net Core version of Console.Waterworks. It is strictly .Net Core; So, it has no .Net Standard or traditional .Net components. If you prefer to work with that version, feel free to do so. It is call Console.Waterworks.Core (C.W.C) and the link for it is as follows:
Because it is port of this project, its wiki focuses on how to **use** it as a NuGet package. If you want to know how it was made, you will need to stick with this wiki. The reason why is because I want to reduce the amount of duplicated information. Both projects are built the same way. So, if you learn one, you have learned the other. The link for C.W.C's wiki is as follows:
@ -2,8 +2,8 @@ From a personal point-of-view, I like to keep "plumbing code" and "business logi
Because this repository does not utilise this set-up, I will provide you with a link to another project which does. It is called Wet Pancake and the links for its repository and wiki are as follows:
Within Wet Pancake is a .Net Standard Library (written in F#) and a .Net 4.7 console project (written in C#). The console project uses Console.Waterworks (C.W.) and references the F# library (yes, two different languages). I am hoping this is convincing enough for you.
This section is for those wanting to work with the repositories source code. If you are more interested in using Console.Waterworks features via NuGet, please use the following links:
- [As a NuGet](NuGet-Home)
- [Using Console.Waterworks.Core as a NuGet](https://gitlab.com/craig.oates/Console.Waterworks.Core/wikis/Wiring-Console.Waterworks.Core-into-Your-Project)
- [Using Console.Waterworks(.Core) in an F# Project](https://gitlab.com/craig.oates/Brittle-Fish/wikis/Home)
- [Using Console.Waterworks.Core as a NuGet](https://git.abbether.net/craig.oates/Console.Waterworks.Core/wikis/Wiring-Console.Waterworks.Core-into-Your-Project)
- [Using Console.Waterworks(.Core) in an F# Project](https://git.abbether.net/craig.oates/Brittle-Fish/wikis/Home)
@ -7,9 +7,9 @@ To use the "Help Section" feature, you will need to know about the four attribut
To you get a sense of how they look in practice, please use the links below:
- [ConsoleCommands.cs](https://gitlab.com/craig.oates/Console.Waterworks/blob/master/Console.Waterworks/CW_Console/ConsoleCommands.cs) (part of CW_Console)
- [Wet Pancakes' ConsoleCommands.cs](https://gitlab.com/craig.oates/Wet-Pancake/blob/master/WetPancakeCLI/ConsoleCommands.cs) (this uses Console.Waterworks in a slightly more advance manner)
- [Smouldering Beach Ball's ConsoleCommands.fs](https://gitlab.com/craig.oates/Smouldering-Beach-Ball/blob/master/SmoulderingBeachBallCLI/ConsoleCommands.fs) (this uses the attributes with F#)
- [ConsoleCommands.cs](https://git.abbether.net/craig.oates/Console.Waterworks/blob/master/Console.Waterworks/CW_Console/ConsoleCommands.cs) (part of CW_Console)
- [Wet Pancakes' ConsoleCommands.cs](https://git.abbether.net/craig.oates/Wet-Pancake/blob/master/WetPancakeCLI/ConsoleCommands.cs) (this uses Console.Waterworks in a slightly more advance manner)
- [Smouldering Beach Ball's ConsoleCommands.fs](https://git.abbether.net/craig.oates/Smouldering-Beach-Ball/blob/master/SmoulderingBeachBallCLI/ConsoleCommands.fs) (this uses the attributes with F#)
You will only see these attributes decorating command-methods found in each project's "ConsoleCommands.cs" file (or ConsoleCommands.fs" file if you're using F#).
If you go through the "Help" section, you will notice most of the commands have input arguments. From your point-of-view, they are typical (input) types (`int`, `string` Etc.). There are limitations to these arguments but you can extend them if you want; I do not recommend you do that, though. If you would like to know more about about these limitations, please use the following link:
You should not notice the limitations for the most part. Although, if you are wanting to work with this projects source code, I recommend you glance at the list in the above link at least.
@ -4,8 +4,8 @@ Having got my feet wet with F#, I started to like it more than C#. One of the th
If you are an F# developer, I am fairly sure you have come across what I call the "F#-Shuffle". The moment you come across some documentation but it's in C# and you need to translate it. I personally found this happened a lot in the early days of me learning F#. That is why I have created a dedicated repository showing how to use C.W. with F#. It is called Brittle Fish and you can find it at the following links:
- [Brittle Fish Repository](https://gitlab.com/craig.oates/Brittle-Fish)
- [Brittle Fish Wiki](https://gitlab.com/craig.oates/Brittle-Fish/wikis/Home)
- [Brittle Fish Repository](https://git.abbether.net/craig.oates/Brittle-Fish)
- [Brittle Fish Wiki](https://git.abbether.net/craig.oates/Brittle-Fish/wikis/Home)
The repository has examples for the traditional .Net and .Net Core frameworks.
@ -50,4 +50,4 @@ A nice side-effect of the attributes is your command-methods are "self-documente
For the sake of completeness, I have provided a link to the `ConsoleCommands` class in CW_Console. Hopefully, seeing more realistic examples will help reduce any confusion. The link is as follows:
What is important to note here is the importance of the command-method names. The names you use are the exact same commands your end-user will enter at run-time. The console's input is, also, case-sensitive. This means you can have two command-methods called `Test` and `test` and have them do different things.
@ -38,6 +37,6 @@ Another feature of C.W. is it parses and coerces input arguments. This means you
To be clear, there are limits to the amount of types you can use with your command-methods. For a full, list of all the coercion types, please refer to the Coercion Types List in the "As Source Code" section. The link for it is as follows:
If you write command-methods with arguments **not** on the coercion list, you will get a run-time error. With that said, you are free to use whatever types you want **inside** the command-methods.
