Added some documentations

Author: eadwinCode

docs/cli/new-command.md

@@ -51,4 +51,57 @@ path/to/scaffold-the-new-project/
 
 ## **New Command CLI Arguments**
 - `project-name` Set the resulting project module name.
-- `directory` Path to dump the scaffolded files. `.` can be used to select current directory.
+- `directory` Path to dump the scaffolded files. `.` can be used to select the current directory.
+
+
+## **New Project without pyproject requirement**
+To scaffold a new project without `pyproject.toml`, add `--plain` to the `ellar new command`. For example,
+
+```shell
+ellar new my-project --plain
+```
+
+This will create a folder as follows:
+```angular2html
+my-project/
+├─ my_project/
+│  ├─ apps/
+│  │  ├─ __init__.py
+│  ├─ core/
+│  ├─ config.py
+│  ├─ domain
+│  ├─ root_module.py
+│  ├─ server.py
+│  ├─ __init__.py
+├─ tests/
+│  ├─ __init__.py
+├─ manage.py
+├─ README.md
+```
+Inside the scaffolded project, the `manage.py` python file is not the entry point for the application.
+It creates a new CLI interface and uses that as the new CLI command to interact with the project.
+
+```shell
+python manage.py
+
+### OUTPUT
+
+Usage: manage.py [OPTIONS] COMMAND [ARGS]...
+
+  Ellar, ASGI Python Web framework
+
+Options:
+  --project TEXT  Run Specific Command on a specific project  [default:
+                  default]
+  -v, --version   Show the version and exit.
+  --help          Show this message and exit.
+
+Commands:
+  create-module  - Scaffolds Ellar Application Module -
+  runserver      - Starts Uvicorn Server -
+
+```
+Other ellar commands and will be executed through `manage.py` python file. Eg:
+```shell
+python manage.py runserver
+```

docs/custom-setup.md

@@ -11,7 +11,7 @@ Create a file `controller.py`:
 ```Python
 from ellar.common import ModuleRouter, Controller, get
 
-router = ModuleRouter('', tag='Math')
+router = ModuleRouter('')
 
 
 @router.get("/add")

docs/index.md

@@ -23,7 +23,7 @@ Ellar was deeply influenced by [NestJS](https://docs.nestjs.com/){target="_blank
 Also, Ellar took some concepts from [FastAPI](https://fastapi.tiangolo.com/){target="_blank"} in terms of request parameter handling and data serialization with Pydantic. 
 
 The objective of Ellar is to provide a high level of abstracted interface to your python web app, along with a well-structured project setup, give room for object-oriented approach to web application design, 
-allow you chose your desired application architecture, and ultimately, deliver speedy handling to requests using any ASGI server.
+allow you to choose your desired application architecture, and ultimately, deliver speedy handling to requests using any ASGI server.
 
 ## **Project Status**
 Beta version

docs/overview/controllers.md

@@ -1,10 +1,11 @@
 # **Controllers**
-The Controller is responsible for handling incoming requests and returning responses to the client.
-The purpose of a controller is to receive specific requests for an application `ApplicationRouter`. `ApplicationRouter` on the other hand, decides which `controller` should handle an incoming request.
+The Controller plays a crucial role in managing incoming requests and providing responses to clients. 
+Its primary function is to handle specific requests directed to an application's `ApplicationRouter`. 
+In turn, the `ApplicationRouter` determines the appropriate `controller` to manage the incoming request.
 
 ![controller description image](../img/controller_description.png)
 
-Controllers can be said to be a router with many routes registered in them.
+Conceptually, controllers can be likened to routers with multiple registered routes within them.
 
 ### **Creating a Controller**
 To create a controller, we use classes and decorators. The `Controller` decorator associates classes with a required
@@ -19,13 +20,13 @@ class UserController(ControllerBase):
 ```
 
 ## **Routing**
-In this section, we are going to highlight key features of the `@Controller()`, a `class decorator` 
-for defining a controller. By default, `@Controller()` will create a path prefix `/car` gotten from the class name in `Car`Controller. 
-This will be used to group related routes and minimize duplicate route definitions.
-
-For example, we may choose to group a set of routes that manage interactions with a customer entity under the route `/user`. 
-In that case, we could specify the path prefix `/user` in the `@Controller()` decorator so we don't have to repeat that portion of the path for each route in the controller.
+In this section, we will outline the key features of `@Controller()`, a `class decorator` designed for defining a controller. 
+By default, when applied, `@Controller()` generates a path prefix based on the class name, such as `/car` 
+for a controller named `CarController`. This feature aims to organize and group related routes, reducing redundancy in route definitions.
 
+For instance, if we want to group a collection of routes managing interactions with a customer entity under the route `/user`, 
+we can specify the path prefix `/user` in the `@Controller()` decorator. 
+This ensures that we don't need to repeat this portion of the path for each route within the controller.
 ```python
 # project_name/apps/car/controllers.py
 
@@ -43,17 +44,20 @@ class CarController(ControllerBase):
 ```
 
 !!! hint
-    Class Decorators name are capitalized while function/method decorator name are in lower case
+    Class decorators are conventionally named with capital letters, while function/method decorator names typically use lowercase letters.
+
 
-The `@get()` HTTP method decorator before the `get_all(self)` method marks `get_all(self)` as the HTTP request handler that will handle a specific endpoint matching the route path and HTTP method of `GET`. 
+The `@get()` HTTP method decorator preceding the `get_all(self)` method designates `get_all(self)` as the HTTP request 
+handler responsible for handling a specific endpoint matching the route path and HTTP method of `GET`.
 
-But what then is the route path of `get_all(self)`? The route path is determined by concatenating the controller `path prefix` and the path specified in the HTTP method function decorator `@get()`.
+But what exactly is the route path for `get_all(self)`? The route path is determined by combining the controller's 
+`path prefix` and the path specified in the HTTP method function decorator `@get()`.
 
-For example, we've declared a prefix for every route `(car)`, and haven't added any path information in the decorator, which means the path will default to `/`. In that case,
-Ellar will map `GET /car/` requests to the `get_all(self)` handler.
+For instance, if we've set a prefix for every route `(car)` and haven't added any path information in the
+decorator, it means the path defaults to `/`. In this case, Ellar will associate `GET /car/` requests with the `get_all(self)` handler.
 
-Another example to help make things clear, a path prefix of `/users` combined with the decorator `@get('/profile')` would produce a route mapping for requests like
-`GET /users/profile`.
+To illustrate further, if we have a path prefix of `/users` and include the decorator `@get('/profile')`, 
+it would result in a route mapping for requests like `GET /users/profile`.
 
 
 ### **Overview of HTTP function decorator parameters:**
@@ -248,10 +252,11 @@ async def create(self, payload: Body[CreateCarSerializer]):
     return 'This action adds a new car'
 ```
 
-`CreateCarSerializer` is a pydantic type. These means `name`, `year` and `model` fields are type validated out of the box. 
+`CreateCarSerializer` is a Pydantic type, which implies that the `name`, `year`, and `model` fields undergo automatic type validation.
 
-It's important to note the way we used `CreateCarSerializer` as a type annotation of the `payload` parameter in the `create` route handler method. 
-Ellar will compute values for all the route handler parameters and validates them based on the annotated types before executing the handler. 
+It's crucial to observe how we utilized `CreateCarSerializer` as a type annotation for the `payload` parameter in the `create` 
+route handler method. Ellar will calculate values for all route handler parameters and validate them according to 
+the annotated types before executing the handler.
 
 !!! info
     if a parameter is not annotated, it will be assumed as a `string` type
@@ -298,11 +303,11 @@ class CarController(ControllerBase):
 ```
 ## **Linking Controller**
 
-In the previous page, we already wired our `car` module (`CarModule`) to `ApplicationModule` in `project_name/root_module` 
-but this time we shall be adding things to the `CarModule`. To keep things more simple, organized, and modular.
+On the preceding page, we successfully connected our `car` module (`CarModule`) to the `ApplicationModule` in `project_name/root_module`. 
+However, this time, we will be introducing modifications to the `CarModule` to keep things simple, organized and modular.
 
-Let's register `CarController` to `CarModule`.
-`@Module()` takes `controllers` as a parameter which is an array of the `ControllerBase` type.
+To achieve this, let's include the registration of `CarController` within the `CarModule`. 
+The `@Module()` decorator accepts a `controllers` parameter, which is an array of the `ControllerBase` type.
 
 In the `car/module.py`,
 

docs/overview/module-router.md

@@ -1,15 +1,14 @@
 # **Module Router**
 
-ModuleRouter allows you to define your route handlers as standalone functions, providing an alternative to using classes. 
-This can be beneficial for python developers who prefer using functions. 
-It is important to note that using ModuleRouter does not limit your access to other features provided by Ellar.
+`ModuleRouter` allows you to define your route handlers as standalone functions, offering an alternative to using classes. 
+This can be advantageous for Python developers who prefer using functions. 
+Importantly, using `ModuleRouter` does not restrict your access to other features provided by Ellar.
 
 ## **Usage**
-The Ellar CLI tool generates a `routers.py` file in every `create-module` scaffold command. 
-This file contains a quick guide on how to use the `ModuleRouter` class.
-
-Let's use the **routers.py** created in our previous project. And create **two** route functions, **addition** and **subtraction** 
+The Ellar CLI tool automatically generates a `routers.py` file with every `create-module` scaffold command. 
+This file serves as a concise guide on utilizing the `ModuleRouter` class.
 
+Now, let's leverage the **routers.py** file generated in our prior project to implement **two** route functions, namely **addition** and **subtraction**.
 ```python
 # project_name/apps/car/routers.py
 """
@@ -23,25 +22,30 @@ def index(request: Request):
     return {'detail': 'Welcome to Cats Resource'}
 """
 from ellar.common import ModuleRouter
+from ellar.openapi import ApiTags
 
-math_router = ModuleRouter('/math', tag='Math')
+math_router = ModuleRouter('/math')
+open_api_tag = ApiTags(name='Math')
+open_api_tag(math_router.get_control_type())
 
 @math_router.get('/add')
-def addition(a:int, b:int):
+def addition(a: int, b: int):
     return a + b
 
 
 @math_router.get('/subtract')
-def subtraction(a:int, b:int):
+def subtraction(a: int, b: int):
     return a - b
+
 ```
-In the example above, we created `math_router` with a prefix `/math` and a OPENAPI tag 'math'. Then we added two routes `addition(a:int, b:int)` and `subtraction(a:int, b:int)`. 
-Each route takes two query parameters, 'a' and 'b' which are declared as int type. These functions handle the query parameters and return the result of the mathematical operation.
 
-Next, we have to make the `math_router` visible to the application
+In the provided example, the `math_router` is created with a prefix `/math` and an OPENAPI tag 'Math'. 
+Two routes, `addition(a:int, b:int)` and `subtraction(a:int, b:int)`, are added to the router, each handling two query parameters ('a' and 'b') of integer type. These functions perform the specified mathematical operations and return the results.
+
+To make the `math_router` visible to the application, it is registered with the current injector using `current_injector.register(ModuleRouter, math_router)`. This step ensures that the router is recognized and accessible within the application.
 
 ## **Registering Module Router**
-Like controllers, ModuleRouters also need to be registered to their root module in order to be used in a web application. 
+Like controllers, ModuleRouters also need to be registered to their root module to be used in a web application. 
 In the example provided above, the `math_router` would be registered under the `project_name/apps/car/module.py` file.
 
 This registration process typically involves importing the `math_router` and then adding it to the list of `routers` in the `module.py` file. 

docs/overview/modules.md

@@ -1,24 +1,25 @@
 # **Modules**
 
-A module is a class annotated with a `@Module()` decorator.
-The `@Module()` decorator provides **metadata** that exports a `Module` data and defines the module structure.
+A module is represented by a class with the `@Module()` decorator. 
+This decorator provides essential metadata, offering a `Module` data structure that outlines the module's architecture.
 
 ![middleware description image](../img/ModuleDescription.png)
 
-The best way to organize your components is to build your projects as `Modules`.
+Organizing components within projects as `Modules` is considered a best practice. 
+The `ApplicationModule` serves as the starting point or root module for constructing the application module tree. 
+This internal data structure facilitates the resolution of relationships, dependencies, and interactions between modules and providers.
 
-The `ApplicationModule` is the entry-point/root module to building the application module tree -
-the internal data structure used to resolve `module` and `provider` relationships and dependencies.
-
-Thus, the architecture resulting from most applications will include multiple modules with closely related **functionality**.
+Consequently, the typical architecture of applications involves multiple modules, each encapsulating closely related functionality.
 
 ## **Feature modules**
-Building an application as a group of feature modules bundled together helps to manage complexity, have a maintainable, extendable, and testable code base, and encourage development using SOLID principles.
-
-A typical example of a feature module is the **car** project. The `CarModule` wraps all the services and controller that manages the `car` resource which makes it easy to maintain, extend, and testable.
-```python title='project_name/apps/car/module.py' linenums="1"
+Building an application as a group of feature modules bundled together helps manage complexity, 
+maintain a codebase that is both extendable and testable, and encourages development using SOLID principles.
 
+A typical example of a feature module is the **car** project. 
+The `CarModule` wraps all the services and controllers responsible for managing the `car` resource, 
+making it easy to maintain, extend, and test.
 
+```python title='project_name/apps/car/module.py' linenums="1"
 from ellar.common import Module
 from ellar.core import ModuleBase
 from ellar.di import Container
@@ -76,22 +77,67 @@ class BookModule(ModuleBase):
 ## **Additional Module Configurations**
 
 ### **Module Events**
-Every registered Module receives two event calls during its instantiation and when the application is ready.
+Before a Module is instantiated, the `before_init` class method is invoked with an application config object. 
+This allows for the configuration of additional initialization parameters that need to be supplied to the `__init__` 
+function, originating from the application config.
 
 ```python linenums="1"
+import typing
 from ellar.common import Module
 from ellar.core import ModuleBase, Config
 
+
 @Module()
 class ModuleEventSample(ModuleBase):
     @classmethod
-    def before_init(cls, config: Config) -> None:
+    def before_init(cls, config: Config) -> typing.Any:
         """Called before creating Module object"""
 
 ```
 `before_init` receives current app `Config` as a parameter for further configurations before `ModuleEventSample` is initiated.
 It's important to note that returned values from `before_init` will be passed to the constructor of `ModuleEventSample` during instantiation.
 
+### **Module Application Cycle**
+The Ellar application follows a two-phase lifecycle, consisting of `on_startup` and `on_shutdown`, which are managed by `EllarApplicationLifespan`.
+
+- `on_startup`: Triggered when the ASGI server initiates a lifespan request on the application instance.
+- `on_shutdown`: Activated when the ASGI server is in the process of shutting down the application.
+
+Modules can subscribe to these events by inheriting from `IApplicationStartup` for startup actions and `IApplicationShutdown` for shutdown actions.
+
+For instance:
+```python
+from ellar.common import Module, IApplicationShutdown, IApplicationStartup
+from ellar.core import ModuleBase
+
+@Module()
+class AModuleSample(ModuleBase, IApplicationStartup):
+    async def on_startup(self, app: "App") -> None:
+        pass
+
+@Module()
+class BModuleSample(ModuleBase, IApplicationShutdown):
+    async def on_shutdown(self) -> None:
+        pass
+
+@Module()
+class CModuleSample(ModuleBase, IApplicationStartup, IApplicationShutdown):
+    async def on_startup(self, app: "App") -> None:
+        pass
+
+    async def on_shutdown(self) -> None:
+        pass
+```
+
+In the provided example:
+- `AModuleSample` subscribes to `IApplicationStartup` and will be called only during startup.
+- `BModuleSample` subscribes to `IApplicationShutdown` and will be called only during application shutdown.
+- `CModuleSample` subscribes to both `IApplicationStartup` and `IApplicationShutdown`, thus being invoked during both startup and shutdown phases.
+
+This modular approach enables modules to actively engage in the application's life-cycle events, allowing developers 
+to organize and execute code efficiently during specific stages. 
+This not only enhances flexibility but also contributes to the overall maintainability of the application.
+
 ### **Module Exceptions**
 Custom exception handlers can be registered through modules.
 
@@ -108,12 +154,11 @@ class ModuleExceptionSample(ModuleBase):
 `exception_404_handler` will be register to the application at runtime during `ModuleExceptionSample` computation.
 
 ### **Module Templating Filters**
-We can also define `Jinja2` templating filters in project Modules or any `@Module()` module.
-The defined filters are be passed down to `Jinja2` **environment** instance alongside the `template_folder` 
-value when creating **TemplateLoader**.
-
-```python linenums="1"
+In addition, we can define `Jinja2` templating filters within project Modules or any module annotated with `@Module()`.
+The specified filters are then passed down to the `Jinja2` **environment** instance alongside the `template_folder` 
+value when creating the **TemplateLoader**.
 
+```python
 from ellar.common import Module, template_global, template_filter
 from ellar.core import ModuleBase
 
@@ -132,6 +177,7 @@ class ModuleTemplateFilterSample(ModuleBase):
         return n * 2
 ```
 
+
 ## **Dependency Injection**
 A module class can inject providers as well (e.g., for configuration purposes):