Merge pull request #99 from eadwinCode/config_with_prefix

Config with prefix

Author: eadwinCode

docs/configurations.md

@@ -251,3 +251,48 @@ To allow any hostname either use `allowed_hosts=["*"]` or omit the middleware.
 Default: `True`
 
 Indicates whether to append `www.` when redirecting host in `TrustedHostMiddleware`
+
+
+## **Configuration with prefix**
+Ellar configuration module also support loading of its configurations with appended prefix. for instance,
+we can have a file `my_settings.py` with some ellar's configurations set to it with some prefix `API_` as shown below.
+
+```python
+# my_settings.py
+API_DEBUG = True
+API_SECRET_KEY = "your-secret-key-changed"
+API_INJECTOR_AUTO_BIND = True
+API_JINJA_TEMPLATES_OPTIONS = {"auto_reload": True}
+
+OTHER_XYZ_CONFIGS_1 ='whatever'
+OTHER_XYZ_CONFIGS_2 ='whatever2'
+```
+To apply these configurations without having to load everything, you have to provide the prefix to be used to load configurations that
+belongs to ellar. For example,
+
+```python
+from ellar.core.factory import AppFactory
+from .root_module import ApplicationModule
+
+application = AppFactory.create_from_app_module(ApplicationModule, config_module=dict(
+    config_module='project_name:my_settings',
+    config_prefix='api_',
+))
+```
+In the above construct, we used a dict object to define the configuration module(`'project_name:my_settings'`) and prefix `api_`. 
+This will be applied to the configuration instance when the application is ready.
+
+## **Defining Configurations directly**
+During application bootstrapping with `AppFactory`, you can define app configurations directly under `config_module` as a dict object as some below.
+
+```python
+from ellar.core.factory import AppFactory
+from .root_module import ApplicationModule
+
+application = AppFactory.create_from_app_module(ApplicationModule, config_module=dict(
+    SECRET_KEY = "your-secret-key-changed",
+    INJECTOR_AUTO_BIND = True,
+    MIDDLEWARE=[],
+    EXCEPTION_HANDLERS=[]
+))
+```

docs/handling-response/response-model.md

@@ -1,4 +1,4 @@
-# Response Model
+# **Response Models**
 
 Each route handler has key-value pair of status codes and a response model. 
 This response model holds information on the type of response to be returned.
@@ -62,7 +62,7 @@ response = {200: JSONResponseModel(model_field_or_schema=UserSchema, description
     Each route handler has its own `ResponseModel` computation and validation. If there is no response definition, Ellar default the route handler model to `EmptyAPIResponseModel`.
 
 
-## Override Response Type
+## **Override Response Type**
 
 When you use a `Response` class as response, a `ResponseModel` is used and the `response_type` is replaced with applied response class.
 
@@ -96,7 +96,7 @@ from ellar.common import PlainTextResponse
 response = {200: ResponseModel(response_type=PlainTextResponse), 201: JSONResponseModel(model_field_or_schema=UserSchema)}
 ```
 
-## Response Model Properties
+## **Response Model Properties**
 
 All response model follows `IResponseModel` contract.
 
@@ -129,7 +129,7 @@ They include:
 - `model_field_or_schema`: `Optional` property. For return data validation. Default: `None` **Optional**
 
 
-## Different Response Models 
+## **Different Response Models**
 Let's see different `ResponseModel` available in Ellar and how you can create one too.
 
 ### **ResponseModel** 
@@ -183,7 +183,7 @@ Default `ResponseModel` applied when no response is defined.
 - model_field_or_schema: `dict`
 - media_type: `application/json`
 
-## Custom Response Model
+## **Custom Response Model**
 
 Lets create a new JSON response model.
 

docs/handling-response/response.md

@@ -1,4 +1,4 @@
-## Introduction
+## **Response and Serializers**
 The `Serializer` class in the Ellar, is a custom class based on `pydantic` models, which provides additional functionality specific to Ellar's requirements.
 
 To use `Serializer` in Ellar, you simply need to create a class that inherits from `Serializer` and define your data model using pydantic fields. 
@@ -17,7 +17,7 @@ class UserSerializer(Serializer):
 With this setup, you can use the `UserSerializer` class to validate incoming data and or serialize outgoing response data, 
 ensuring that it matches the expected format before saving it to the database or returning it to the client.
 
-## Handling Responses
+## **Handling Responses**
 
 Let's see how we can use **Serializer** as a responses schema which will help us validate out data output and also provide documentation on route function response.
 
@@ -71,7 +71,7 @@ that can be easily serialized to JSON.
 The resulting dictionary is then passed to the [`JSONResponseModel`](./response-model/#jsonresponsemodel) for serialization to a 
 JSON string and sending the response to the client.
 
-## Using Dataclass as Response Schema
+## **Using Dataclass as Response Schema**
 We can utilize the `dataclasses` feature as a response schema by utilizing the `DataclassSerializer` a base class. 
 
 For instance, we can convert the `UserSchema` to a dataclass by defining `UserDataclass` as follows:
@@ -92,7 +92,7 @@ class UserDataclass(DataclassSerializer):
 
 By replacing the `UserSchema` with `UserDataclass`, we can expect the same outcomes in the returned response, response validation, and documentation.
 
-### Multiple Response Types
+### **Multiple Response Types**
 
 The `response` parameter takes different shape. Let's see how to return a different response if the user is not authenticated.
 
@@ -156,7 +156,7 @@ Here, the `response` parameter takes a KeyValuePair of the `status` and response
 
 
 
-## Using Response Type/Object As Response
+## **Using Response Type/Object As Response**
 
 You can use `Response` type to change the format of data returned from endpoint functions.
 

docs/parsing-inputs/body.md

@@ -1,4 +1,4 @@
-# Request Body
+# **Request Body**
 
 Request bodies are typically used with “create” and “update” operations (POST, PUT, PATCH).
 For example, when creating a resource using POST or PUT, the request body usually contains the representation of the resource to be created.
@@ -8,7 +8,7 @@ To declare a **request body**, you need to use **Ellar `Serializer`**.
 !!! info
     Under the hood **Ellar** uses <a href="https://pydantic-docs.helpmanual.io/" class="external-link" target="_blank">Pydantic</a> models with all their power and benefits.
 
-## Import Serializer
+## **Import Serializer**
 
 First, you need to import `Serializer` from `ella.serializer`:
 
@@ -24,7 +24,7 @@ from ellar.common import Serializer
 
 ```
 
-## Create your data model
+## **Create your data model**
 
 Then you declare your data model as a class that inherits from `Serializer`.
 
@@ -71,7 +71,7 @@ For example, this model above declares a JSON "`object`" (or Python `dict`) like
 }
 ```
 
-## Declare it as a parameter
+## **Declare it as a parameter**
 
 To add it to your *path operation*, declare it the same way you declared the path and query parameters:
 
@@ -97,7 +97,7 @@ class ItemsController(ControllerBase):
 
 ... and declare its type as the model you created, `Item`.
 
-## Results
+## **Results**
 
 With just that Python type declaration, **Ellar** will:
 
@@ -112,7 +112,7 @@ With just that Python type declaration, **Ellar** will:
   your models, and you can also use them anywhere else you like if it makes sense for your project.
 * Those schemas will be part of the generated OpenAPI schema, and used by the automatic documentation <abbr title="User Interfaces">UI's</abbr>.
 
-## Automatic Docs
+## **Automatic Docs**
 
 The JSON Schemas of your models will be part of your OpenAPI generated schema, and will be shown in the interactive API docs:
 
@@ -123,7 +123,7 @@ The JSON Schemas of your models will be part of your OpenAPI generated schema, a
 ![Openapi schema](../img/body-schema-doc2.png)
 
 
-## Request Body + Path parameters
+## **Request Body + Path parameters**
 
 You can declare path parameters **and** body requests at the same time.
 
@@ -152,7 +152,7 @@ class ItemsController(ControllerBase):
         return {"item_id": item_id, "item": item.dict()}
 ```
 
-## Request Body + Path + Query parameters
+## **Request Body + Path + Query parameters**
 
 You can also declare **body**, **path** and **query** parameters, all at the same time.
 
@@ -191,7 +191,7 @@ The function parameters will be recognized as follows:
     In here, we have combined both `Serializers` and `Controllers` in one file. This is for the convenience of writing this documentation.
     It's advised to have all your serializers in `schemas.py` and then import them over to `controllers.py` if needed.
 
-## Singular values in body
+## **Singular values in body**
 The same way there is a `Query` and `Path` to define extra data for query and path parameters, 
 **Ellar** provides an equivalent `Body`.
 
@@ -253,7 +253,7 @@ In this case, **Ellar** will expect a body like:
 }
 ```
 
-## Multiple body params and query
+## **Multiple body params and query**
 Of course, you can also declare additional `query` parameters whenever you need, additional to anybody parameters.
 
 As, by default, singular values are interpreted as query parameters, you don't have to explicitly add a `Query`, you can just do:

docs/parsing-inputs/cookie-params.md

@@ -1,12 +1,12 @@
-# Cookie Parameters
+# **Cookie Parameters**
 
 You can define Cookie parameters the same way you define `Path` parameters.
 
-## Import `Cookie`
+## **Import `Cookie`**
 
 First import `Cookie` from `ellar.common` module
 
-## Declare `Cookie` parameters
+## **Declare `Cookie` parameters**
 
 Then declare the cookie parameters using the same structure as with `Path` and `Query`.
 
@@ -29,7 +29,7 @@ class ItemsController(ControllerBase):
 !!! info
     To declare cookies, you need to use `Cookie`, because otherwise the parameters would be interpreted as `query` parameters.
 
-### Using Schema
+## **Using Schema**
 
 You can also use Schema to encapsulate `Cookies` parameters:
 

docs/parsing-inputs/file-params.md

@@ -1,4 +1,4 @@
-# File uploads
+# **File Uploads**
 
 Handling files are no different from other parameters.
 You can define files to be uploaded by using `File`.
@@ -10,11 +10,11 @@ You can define files to be uploaded by using `File`.
 
     This is because uploaded files are sent as "form data".
 
-## Import `File`
+## **Import `File`**
 
 First import `File` from `ellar.common` module
 
-## Define `File` parameters
+## **Define `File` parameters**
 
 Create file parameters the same way you would for `Body` or `Form`:
 
@@ -38,7 +38,7 @@ Have in mind that this means that the whole contents will be stored in memory. T
 
 But there are several cases in which you might benefit from using `UploadFile`.
 
-## `File` parameters with `UploadFile`
+## **`File` parameters with `UploadFile`**
 
 Define a `File` parameter with a type of `UploadFile`:
 
@@ -106,7 +106,7 @@ contents = myfile.file.read()
     **Ellar**'s `UploadFile` inherits directly from **Starlette**'s `UploadFile`, but adds some necessary parts to make it compatible with **Pydantic** and the other parts of Ellar.
 
 
-## Uploading array of files
+## **Uploading array of files**
 
 To **upload several files** at the same time, just declare a `List` of `UploadFile`:
 
@@ -124,7 +124,7 @@ class ItemsController(ControllerBase):
         return [f.filename for f in files]
 ```
 
-## Uploading files with extra fields
+## **Uploading files with extra fields**
 
 Note: HTTP protocol does not allow you to send files in application/json format by default (unless you encode it somehow to JSON on client side)
 

docs/parsing-inputs/form-params.md

@@ -1,4 +1,4 @@
-# Form data
+# **Form Data**
 
 **Ellar** also allows you to parse and validate `request.POST` data
 (aka `application x-www-form-urlencoded` or `multipart/form-data`).
@@ -10,7 +10,7 @@ When you need to receive form fields instead of JSON, you can use `Form`.
     E.g. `pip install python-multipart`.
 
 
-## Form Data as params 
+## **Form Data as params** 
 
 ```python
 # project_name/apps/items/controllers.py
@@ -39,7 +39,7 @@ from ellar.common import Form
 username: str = Form()
 ```
 
-## Using a Schema
+## **Using a Schema**
 
 In a similar manner to [Body](../body/#declare-it-as-a-parameter), you can use
 a Schema to organize your parameters.
@@ -66,7 +66,7 @@ class ItemsController(ControllerBase):
 
 ![Openapi schema](../img/form-schema-doc.png)
 
-## Request form + path + query parameters
+## **Request form + path + query parameters**
 
 In a similar manner to [Body](../body/#request-body-path-query-parameters), you can use
 Form data in combination with other parameter sources.
@@ -101,7 +101,7 @@ class ItemsController(ControllerBase):
         return {"item_id": item_id, "item": item.dict(), "q": q}
 ```
 
-## Mapping Empty Form Field to Default
+## **Mapping Empty Form Field to Default**
 
 Form fields that are optional, are often sent with an empty value. This value is
 interpreted as an empty string, and thus may fail validation for fields such as `int` or `bool`.

docs/parsing-inputs/header-params.md

@@ -1,14 +1,14 @@
-# Header Parameters
+# **Header Parameters**
 
 You can define Header parameters the same way you define `Query`, `Path` and `Cookie` parameters.
 
 To query this operation, you use a URL like:
 
-## Import `Header`
+## **Import `Header`**
 
 First import `Header` from `ellar.common` module
 
-## Declare `Header` parameters
+## **Declare `Header` parameters**
 
 Then declare the header parameters using the same structure as with `Path`, `Query` and `Cookie`.
 
@@ -31,7 +31,7 @@ class ItemsController(ControllerBase):
 !!! info
     To declare headers, you need to use `Header`, because otherwise the parameters would be interpreted as query parameters.
 
-## Automatic conversion
+## **Automatic conversion**
 
 `Header` has a little extra functionality.
 
@@ -67,7 +67,7 @@ class ItemsController(ControllerBase):
     Before setting `convert_underscores` to `False`, bear in mind that some HTTP proxies and servers disallow the usage of headers with underscores.
 
 
-## Duplicate headers
+## **Duplicate headers**
 
 It is possible to receive duplicate headers. That means, the same header with multiple values.
 
@@ -109,7 +109,7 @@ The response would be like:
 }
 ```
 
-### Using Schema
+## **Using Schema**
 
 You can also use Schema to encapsulate `Header` parameters:
 

docs/parsing-inputs/index.md

@@ -1,4 +1,4 @@
-# Intro
+# **Input Parsing Tutorial**
 
 In this section, we are going to learn how inputs are parsed in the Ellar route handle functions.
 
@@ -44,7 +44,7 @@ visit [http://localhost:8000/items/](http://localhost:8000/items/),
 All code example will be done on the `ItemController` in `project_name/apps/items/controllers.py`. 
 Please keep it open.
 
-## Tutorial
+## **Tutorial**
 You are going to learn how to use the following route handler parameter:
 
 - [Path](./path-params)