update nav

docs/FastAPI/01_fastapi_application___routing.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "FastAPI Application & Routing"
+parent: "FastAPI"
+nav_order: 1
+---
+
 # Chapter 1: FastAPI Application & Routing
 
 Welcome to your first adventure with FastAPI! 👋

docs/FastAPI/02_path_operations___parameter_declaration.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Path Operations & Parameter Declaration"
+parent: "FastAPI"
+nav_order: 2
+---
+
 # Chapter 2: Path Operations & Parameter Declaration
 
 Welcome back! In [Chapter 1: FastAPI Application & Routing](01_fastapi_application___routing.md), we learned how to set up a basic FastAPI application and organize our code using `APIRouter`. We saw how to connect a URL like `/` to a Python function using `@app.get("/")`.

docs/FastAPI/03_data_validation___serialization__pydantic_.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Data Validation & Serialization (Pydantic)"
+parent: "FastAPI"
+nav_order: 3
+---
+
 # Chapter 3: Data Validation & Serialization (Pydantic)
 
 Welcome back! In [Chapter 2: Path Operations & Parameter Declaration](02_path_operations___parameter_declaration.md), we learned how FastAPI uses type hints to understand path parameters (like `/items/{item_id}`) and query parameters (like `/?skip=0&limit=10`). We even saw a sneak peek of how Pydantic models can define the structure of a JSON request body.

docs/FastAPI/04_openapi___automatic_docs.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "OpenAPI & Automatic Docs"
+parent: "FastAPI"
+nav_order: 4
+---
+
 # Chapter 4: OpenAPI & Automatic Docs
 
 Welcome back! In [Chapter 3: Data Validation & Serialization (Pydantic)](03_data_validation___serialization__pydantic_.md), we saw how FastAPI uses Pydantic models to automatically validate incoming data and serialize outgoing data, making our API robust and predictable. But how do we tell others (or remind ourselves later) how to actually *use* our API? What endpoints exist? What data should they send? What will they get back?

docs/FastAPI/05_dependency_injection.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Dependency Injection"
+parent: "FastAPI"
+nav_order: 5
+---
+
 # Chapter 5: Dependency Injection
 
 Welcome back! In [Chapter 4: OpenAPI & Automatic Docs](04_openapi___automatic_docs.md), we saw how FastAPI automatically generates interactive documentation for our API, making it easy for others (and ourselves!) to understand and use. This works because FastAPI understands the structure of our paths, parameters, and Pydantic models.

docs/FastAPI/06_error_handling.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Error Handling"
+parent: "FastAPI"
+nav_order: 6
+---
+
 # Chapter 6: Error Handling
 
 Welcome back! In [Chapter 5: Dependency Injection](05_dependency_injection.md), we learned how to structure our code using dependencies to manage common tasks like pagination or database sessions. This helps keep our code clean and reusable.

docs/FastAPI/07_security_utilities.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Security Utilities"
+parent: "FastAPI"
+nav_order: 7
+---
+
 # Chapter 7: Security Utilities
 
 Hi there! 👋 In [Chapter 6: Error Handling](06_error_handling.md), we learned how to handle situations where things go wrong in our API, like when a user requests an item that doesn't exist. Now, let's talk about protecting our API endpoints.

docs/FastAPI/08_background_tasks.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Background Tasks"
+parent: "FastAPI"
+nav_order: 8
+---
+
 # Chapter 8: Background Tasks
 
 Welcome back! In [Chapter 7: Security Utilities](07_security_utilities.md), we learned how to protect our API endpoints using FastAPI's security features. Now, let's explore how to perform actions *after* we've already sent a response back to the user.

docs/Flask/01_application_object___flask__.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Application Object (Flask)"
+parent: "Flask"
+nav_order: 1
+---
+
 # Chapter 1: Application Object (`Flask`)
 
 Welcome to your first step into the world of Flask! Flask is a "microframework" for building web applications in Python. "Micro" doesn't mean it's limited; it means Flask provides the essentials to get started quickly, letting you add features as needed.

docs/Flask/02_routing_system.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Routing System"
+parent: "Flask"
+nav_order: 2
+---
+
 # Chapter 2: Routing System
 
 Welcome back! In [Chapter 1: Application Object (`Flask`)](01_application_object___flask__.md), we learned how to create the central `app` object, the control tower for our Flask application. We even added a simple "Hello, World!" page using `@app.route('/')`.

docs/Flask/03_request_and_response_objects.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Request and Response Objects"
+parent: "Flask"
+nav_order: 3
+---
+
 # Chapter 3: Request and Response Objects
 
 Welcome back! In [Chapter 2: Routing System](02_routing_system.md), we learned how Flask uses routes (`@app.route(...)`) to direct incoming web requests to the correct Python view functions. We saw how to create static routes like `/about` and dynamic routes like `/user/<username>`.

docs/Flask/04_templating__jinja2_integration_.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Templating (Jinja2 Integration)"
+parent: "Flask"
+nav_order: 4
+---
+
 # Chapter 4: Templating (Jinja2 Integration)
 
 Welcome back! In [Chapter 3: Request and Response Objects](03_request_and_response_objects.md), we saw how to handle incoming requests and craft outgoing responses. We even created a simple HTML form, but we had to write the HTML code directly as a string inside our Python function. Imagine building a whole website like that – it would get very messy very quickly!

docs/Flask/05_context_globals___current_app____request____session____g__.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Context Globals"
+parent: "Flask"
+nav_order: 5
+---
+
 # Chapter 5: Context Globals (`current_app`, `request`, `session`, `g`)
 
 Welcome back! In [Chapter 4: Templating (Jinja2 Integration)](04_templating__jinja2_integration_.md), we learned how to separate our HTML structure from our Python code using templates and the `render_template` function. We saw how variables like `request` and functions like `url_for` seemed to be magically available in our templates.

docs/Flask/06_configuration___config__.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Configuration (config)"
+parent: "Flask"
+nav_order: 6
+---
+
 # Chapter 6: Configuration (`Config`)
 
 Welcome back! In [Chapter 5: Context Globals (`current_app`, `request`, `session`, `g`)](05_context_globals___current_app____request____session____g__.md), we saw how Flask uses context globals like `current_app` and `session`. We even learned that using the `session` requires setting a `SECRET_KEY` on our application object. But where is the best place to put settings like the secret key, or maybe a database connection string, or a flag to turn debugging features on or off? We definitely don't want to hardcode these directly into our main application logic!

docs/Flask/07_application_and_request_contexts.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Application and Request Contexts"
+parent: "Flask"
+nav_order: 7
+---
+
 # Chapter 7: Application and Request Contexts
 
 Welcome back! In [Chapter 6: Configuration (`Config`)](06_configuration___config__.md), we learned how to manage settings for our Flask application using the `app.config` object. And in [Chapter 5: Context Globals (`current_app`, `request`, `session`, `g`)](05_context_globals___current_app____request____session____g__.md), we met special variables like `request` and `current_app` that seem to magically know about the current request or application.

docs/Flask/08_blueprints.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Blueprints"
+parent: "Flask"
+nav_order: 8
+---
+
 # Chapter 8: Blueprints
 
 Welcome back! In [Chapter 7: Application and Request Contexts](07_application_and_request_contexts.md), we explored the "magic" behind Flask's context system, understanding how variables like `request` and `current_app` work reliably even with multiple concurrent requests.