Merge pull request #45 from eadwinCode/doc_image_update

Documentation Image Update

Author: eadwinCode

docs/img/ModuleDescription.png

@@ -1,25 +1,9 @@
 
 The Controller is responsible for handling incoming requests and returning responses to client. 
 The purpose of a controller is to receive specific requests for an application and `ApplicationRouter` decides which controller should handle an incoming request.
-```
-                                                                         ┌───────────────────┐
-                                                                  ┌─────►│ controller        │
-                                                                  │      └───────────────────┘
-                                                                  │
-                                                                  │
-                                                                  │
-                                                                  │
-                                                                  │
-┌─────────────────────┐                 ┌────────────────────┐    │
-│  client  requests   ├─◄──────────────►│ Application Router ├─◄──┤
-└─────────────────────┘                 └────────────────────┘    │
-                                                                  │
-                                                                  │
-                                                                  │
-                                                                  │      ┌────────────────────┐
-                                                                  └─────►│ controller         │
-                                                                         └────────────────────┘
-```
+
+![controller description image](../img/controller_description.png)
+
 Controllers can also be seen as a router which has many routes registered in it.
 
 ### Creating a Controller
@@ -74,7 +58,7 @@ For example, a path prefix of `/users` combined with the decorator `@get('/profi
 `GET /users/profile`.
 
 
-#### Overview of HTTP function decorator parameters:
+### Overview of HTTP function decorator parameters:
 
 `@get(path: str, name: str, include_in_schema: bool, response: t.Union[t.Dict[int, t.Type], t.List[t.Tuple[int, t.Type]], t.Type])`
 
@@ -88,8 +72,9 @@ Ellar will always serialize all HTTP handler functions returned data as `json` u
 For the above example, `get_all` returned a string. This will be serialized to json with a `status code` 200.
 
 
-## Request object
-There are different ways handlers can access client request details
+## Request Object
+There are different ways handlers can access client request details:
+
 - Annotation (`parameter_name:Request`)
 Ellar will resolve any parameter annotated as `Request` in request handler signature as `Request` object.
 ```python
@@ -265,7 +250,9 @@ async def create(self, payload: CreateDogSerializer = Body()):
 ```
 
 `CreateDogSerializer`, a pydantic type, so fields(`name`, `age`, `breed`) validations according to defined types and
-specifications is supported out of the box. It's important to note the way we used `CreateDogSerializer` as a type annotation to `payload` parameter in `create` method. 
+specifications is supported out of the box. 
+
+It's important to note the way we used `CreateDogSerializer` as a type annotation to `payload` parameter in `create` method. 
 During request Ellar computes the route handler signatures and validates them to the annotated types before executing the handler.
 
 ![CreateDogSchema](../img/create-dog-schema.png)

docs/img/controller_description.png

@@ -1,16 +1,7 @@
 Middlewares are functions that are called during request before hitting a specific route handler. 
 Middleware functions can modify **request** and **response** objects during `http` or `websocket` connection. 
 
-```
-                                                ┌────────────────────────────┐
-┌──────────────────────┐  request               │                            │   request          ┌────────────────────────────┐
-│                      ├───────────────────────►│   CORSMiddleware           ├──────────────────► │                            │
-│  Client Request      │                        │                            │                    │  Route Handler             │
-│                      │◄────────────────────── │   TrustedHostMiddleware    │◄────────────────── │                            │
-└──────────────────────┘     response           │                            │   response         └────────────────────────────┘
-                                                │   ....                     │
-                                                └────────────────────────────┘
-```
+![middleware description image](../img/middleware.png)
 
 Ellar Middlewares follows [`Starlette ASGI Middleware`](https://www.starlette.io/middleware/) pattern 
 and are set up in a pipeline nature to have a request-response cycle behaviour.
@@ -24,6 +15,7 @@ During request, each `ASGI` Middleware must call the ASGI `app` passed to it dur
         pass
 
     ```
+
 ```python
 # ASGI Middleware Interface
 import typing as t
@@ -40,6 +32,7 @@ class EllarASGIMiddlewareStructure:
 ```
 
 Actions that can be performed by middleware functions:
+
 - Execute any code
 - Make changes to request and response objects
 - End the request-response cycle if need be
@@ -96,7 +89,7 @@ class DevelopmentConfig(BaseConfig):
     ]
 
 ```
-This is how to apply any `ASGI` middlewares such as `GZipMiddleware`, `EllarASGIMiddlewareStructure` and others available in `Starlette` library to `Ellar` application
+This is how to apply any `ASGI` middlewares such as `GZipMiddleware`, `EllarASGIMiddlewareStructure` and others available in `Starlette` library.
 
 ## Starlette Middlewares
 Let's explore other Starlette middlewares and other third party ASGI Middlewares

docs/img/middleware.png

@@ -1,32 +1,8 @@
 A module is a class annotated with a `@Module()` decorator. 
 The `@Module()` decorator provides **metadata** that **Ellar** makes use of to organize the application structure.
-```
-                                           ┌──────────────────────────────┐
-                                           │                              │
-                      ┌──────────────────► │     ApplicationModule        │ ◄─────────────────────────┐
-                      │                    │                              │                           │
-                      │                    └──────────────────────────────┘                           │
-                      │                                    ▲                                          │
-                      │                                    │                                          │
-                      │                                    │                                          │
-                      │                                    │                                          │
-                      │                                    │                                          │
-        ┌─────────────┴─────────────┐           ┌──────────┴─────────────────┐         ┌──────────────┴───────────────┐
-        │                           │           │                            │         │                              │
-        │   BooksModule             │           │   StoreModule              │    ┌───►│       OrderModule            │ ◄──────┐
-        │                           │           │                            │    │    │                              │        │
-        └───────────────────────────┘           └────────────────────────────┘    │    └──────────────────────────────┘        │
-               ▲                                                                  │                                            │
-               │                                                                  │                                            │
-               │                                                                  │                                            │
-               │                                                                  │                                            │
-               │                                                                  │                                            │
-┌──────────────┴────────────┐                                        ┌────────────┴────────────────┐     ┌─────────────────────┴────────┐
-│                           │                                        │                             │     │                              │
-│    SubscriptionModule     │                                        │    AnyFeatureModule1        │     │      AnyFeatureModule2       │
-│                           │                                        │                             │     │                              │
-└───────────────────────────┘                                        └─────────────────────────────┘     └──────────────────────────────┘
-```
+
+![middleware description image](../img/ModuleDescription.png)
+
 The `ApplicationModule` is the entry point for Ellar to build your application graph - 
 the internal data structure used to resolve module and provider relationships and dependencies.
 The best way to organize your components is to build your projects as `Modules`. 
@@ -95,6 +71,7 @@ class BookModule(ModuleBase):
 | `static_folder`   | defines the static folder for this module                                                                                    |
 | `template_folder` | defines the template folder for this module                                                                                  |
 
+
 ## `Additional Module Configurations`
 ### `Module Events`
 Every registered Module receives two event calls during its instantiation and when application is ready.

docs/overview/controllers.md

@@ -28,7 +28,7 @@ class UserRepository:
 
 class UserController(ControllerBase):
     def __init__(self, user_repo: UserRepository) -> None:
-        self.userRepo = user_repo
+        self.user_repo = user_repo
 ```
 In our previous `Dogs` module, we can refactor the `DogsController` and move some actions to a service.
 
@@ -87,13 +87,14 @@ class DogsController(ControllerBase):
 
     ...
 ```
+
 We have defined `DogsRepository` as a dependency to `DogsController` which means Ellar will resolve `DogsRepository` instance when creating `DogsController` instance.
 This was made possible by type definition on `dog_repo` parameter and with the type defined, Ellar knows the provider to look for.
 
 !!! info
     Every class dependencies should be defined in the class **constructor**, that way Ellar will resolve all the dependencies needed for an object instantiation.
 
-## Provider registration
+## Provider Registration
 To get this working, we need to expose the `DogsRepository` to the `DogsModule` module just like we did for the `DogsController`.
 
 ```python
@@ -120,7 +121,10 @@ class DogsModule(ModuleBase):
 
 ## Provider Scopes
 There are different scope which defines different ways a service is instantiated.
-- `transient_scope`: Whenever a transient scoped provider is required, a new instance of the provider is created
+
+### `transient_scope`: 
+Whenever a transient scoped provider is required, a new instance of the provider is created
+
 ```python
 from ellar.di import EllarInjector, transient_scope, injectable
 
@@ -140,7 +144,10 @@ a_transient_instance_2 = injector.get(ATransientClass)
 
 assert a_transient_instance_2 != a_transient_instance_1 # True
 ```
-- `singleton_scope`: A singleton scoped provider is created once throughout the lifespan of the Container instance. For example
+
+### `singleton_scope`: 
+A singleton scoped provider is created once throughout the lifespan of the Container instance. For example
+
 ```python
 from ellar.di import EllarInjector, singleton_scope, injectable
 
@@ -161,8 +168,10 @@ a_singleton_instance_2 = injector.get(ASingletonClass)
 assert a_singleton_instance_2 == a_singleton_instance_1 # True
 ```
 
-- `request_scope`: A request scoped provider is instantiated once during the scope of the request. And its destroyed once the request is complete.
+### `request_scope`: 
+A request scoped provider is instantiated once during the scope of the request. And its destroyed once the request is complete.
 It is important to noted that `request_scope` behaves like a `singleton_scope` during HTTPConnection mode and behaves like a `transient_scope` outside a HTTPConnection mode.
+
 ```python
 from ellar.di import EllarInjector, request_scope, injectable, RequestServiceProvider
 
@@ -190,7 +199,8 @@ assert request_instance_2 != request_instance_1
 
 ## Provider Configurations
 There are two ways we can configure providers that are required in EllarInjector IoC.
-- `ProviderConfig`:
+
+### `ProviderConfig`:
 With `ProviderConfig` we can register `base_type` against a `concrete_type` or register a `base_type` against a value type.
 
 For example:
@@ -244,7 +254,7 @@ assert a_module_instance.ifoo_b == a_foo_instance
 In above example, we used `ProviderConfig` as a value type as in the case of `IFooB` type and 
 as a concrete type as in the case of `IFoo` type.
 
-- `register_providers`:
+### `register_providers`:
 We can also achieve the same by overriding `register_providers` in any Module class.
 
 For example: