Although the system has a restricted input-output (I/O) flow from the outside, the internal flow is a bit more flexible. There is still a rigidity to it but it is not as one-dimensional. To help explain, please consider the image below.
How this works is GridPainter receives input, usually a record type provided by Domain. From there, GridPainter will validate the input by making calls to ValidationServices. If the input is valid, GridPainter calls into ImageServices which then makes the various calls into ColourServices and ImagePrep. When the task is complete, ImagesServices returns the output to GridPainter which then returns it to your/the bigger system. If the input is invalid, DeathSocket will throw a FileNotFoundExcpetion.
If you decide to add new features to the library, please try to keep to this flow/structure.
Note: The modules listed above are situated in files with the same names -- for example, GridPainter resides in "GridPainter.fs", Domain resides in "Domain.fs" Etc.
| Module Name | Name-Space | File Location |
|---|---|---|
GridPainter |
DeathSocket |
GridPainter.fs |
ColourServices |
N.A. | ColourServices.fs |
Domain |
DeathSocket |
Domain.fs |
ImageServices |
N.A. | ImageServices.fs |
ImagePrep |
N.A. | ImagePrep.fs |
ValidationServices |
N.A. | ValidationServices.fs |
Table of Contents
As Source Code
DeathSocket
- DeathSocket Home
- DeathSocket Project Breakdown
- DeathSocket's Main Files Overview
- DeathSocket's Flow
- DeathSocket's Internal Flow
- ScratchPad Overview
DeathSocketCLI
- DeathSocketCLI Home
- C.L.I. Project Breakdown
- The C.L.I's Flow
- Creating the Input-loop
- Command-Methods Overview
- C.L.I. Validation Overview
- Changing the C.L.I. Icon
TestCentre
- TestCentre Home
- TestCentre Breakdown
- Property and Unit Tests Overview
- Console and Library Tests Overview
As a Command-Line Interface (C.L.I.)
- C.L.I. Home
- Add DeathSocketCLI to Your Machine
- Using the Console Program
- Console A.P.I.
- C.L.I. Aliases