You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/customization.qmd
+2-70Lines changed: 2 additions & 70 deletions
Original file line number
Diff line number
Diff line change
@@ -141,74 +141,6 @@ Pydantic is used for data validation and serialization. It ensures that the data
141
141
142
142
If a user-submitted form contains data that has the wrong number, names, or types of fields, Pydantic will raise a `RequestValidationError`, which is caught by middleware and converted into an HTTP 422 error response.
143
143
144
-
For other, custom validation logic, we add Pydantic `@field_validator` methods to our Pydantic request models and then add the models as dependencies in the signatures of corresponding POST routes. FastAPI's dependency injection system ensures that dependency logic is executed before the body of the route handler.
145
-
146
-
#### Defining request models and custom validators
147
-
148
-
For example, in the `UserRegister` request model in `routers/authentication.py`, we add a custom validation method to ensure that the `confirm_password` field matches the `password` field. If not, it raises a custom `PasswordMismatchError`:
149
-
150
-
```python
151
-
classPasswordMismatchError(HTTPException):
152
-
def__init__(self, field: str="confirm_password"):
153
-
super().__init__(
154
-
status_code=422,
155
-
detail={
156
-
"field": field,
157
-
"message": "The passwords you entered do not match"
When the user submits the form, Pydantic will first check that all expected fields are present and match the expected types. If not, it raises a `RequestValidationError`. Then, it runs our custom `field_validator`, `validate_passwords_match`. If it finds that the `confirm_password` field does not match the `password` field, it raises a `PasswordMismatchError`. These exceptions can then be caught and handled by our middleware.
185
-
186
-
(Note that these examples are simplified versions of the actual code.)
187
-
188
-
#### Converting form data to request models
189
-
190
-
In addition to custom validation logic, we also need to define a method on our request models that converts form data into the request model. Here's what that looks like in the `UserRegister` request model from the previous example:
191
-
192
-
```python
193
-
classUserRegister(BaseModel):
194
-
# ...
195
-
196
-
@classmethod
197
-
asyncdefas_form(
198
-
cls,
199
-
name: str= Form(...),
200
-
email: EmailStr = Form(...),
201
-
password: str= Form(...),
202
-
confirm_password: str= Form(...)
203
-
):
204
-
returncls(
205
-
name=name,
206
-
email=email,
207
-
password=password,
208
-
confirm_password=confirm_password
209
-
)
210
-
```
211
-
212
144
### Middleware exception handling
213
145
214
146
Middlewares—which process requests before they reach the route handlers and responses before they are sent back to the client—are defined in `main.py`. They are commonly used in web development for tasks such as error handling, authentication token validation, logging, and modifying request/response objects.
@@ -220,8 +152,8 @@ Middleware functions are decorated with `@app.exception_handler(ExceptionType)`
220
152
Here's a middleware for handling the `PasswordMismatchError` exception from the previous example, which renders the `errors/validation_error.html` template with the error details:
0 commit comments