From 581aa6b08f5126f17df914a8b9431bc415f1abb2 Mon Sep 17 00:00:00 2001 From: zachary62 Date: Fri, 4 Apr 2025 14:20:15 -0400 Subject: [PATCH] update nav --- docs/OpenManus/06_schema.md | 7 +++++++ docs/OpenManus/07_configuration__config_.md | 7 +++++++ docs/OpenManus/08_dockersandbox.md | 7 +++++++ docs/OpenManus/09_mcp__model_context_protocol_.md | 7 +++++++ docs/Pydantic Core/01_basemodel.md | 7 +++++++ .../02_fields__fieldinfo___field_function_.md | 7 +++++++ .../03_configuration__configdict___configwrapper_.md | 7 +++++++ .../04_custom_logic__decorators___annotated_helpers_.md | 7 +++++++ .../05_core_schema___validation_serialization.md | 7 +++++++ docs/Pydantic Core/06_typeadapter.md | 7 +++++++ docs/Requests/01_functional_api.md | 7 +++++++ docs/Requests/02_request___response_models.md | 7 +++++++ docs/Requests/03_session.md | 7 +++++++ docs/Requests/04_cookie_jar.md | 7 +++++++ docs/Requests/05_authentication_handlers.md | 7 +++++++ docs/Requests/06_exception_hierarchy.md | 7 +++++++ docs/Requests/07_transport_adapters.md | 7 +++++++ docs/Requests/08_hook_system.md | 7 +++++++ 18 files changed, 126 insertions(+) diff --git a/docs/OpenManus/06_schema.md b/docs/OpenManus/06_schema.md index 0076c2f..32f070f 100644 --- a/docs/OpenManus/06_schema.md +++ b/docs/OpenManus/06_schema.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "Schema" +parent: "OpenManus" +nav_order: 6 +--- + # Chapter 6: Schema - The Official Data Forms In [Chapter 5: BaseFlow](05_baseflow.md), we saw how Flows act like project managers, coordinating different [Agents](03_baseagent.md) and [Tools](04_tool___toolcollection.md) to complete complex tasks. But for all these different parts (Flows, Agents, LLMs, Tools) to work together smoothly, they need to speak the same language and use the same formats when exchanging information. diff --git a/docs/OpenManus/07_configuration__config_.md b/docs/OpenManus/07_configuration__config_.md index f5c8812..c96383b 100644 --- a/docs/OpenManus/07_configuration__config_.md +++ b/docs/OpenManus/07_configuration__config_.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "Configuration (config)" +parent: "OpenManus" +nav_order: 7 +--- + # Chapter 7: Configuration (Config) Welcome to Chapter 7! In [Chapter 6: Schema](06_schema.md), we learned how OpenManus uses schemas to define the structure of data passed between different components, like official forms ensuring everyone fills them out correctly. diff --git a/docs/OpenManus/08_dockersandbox.md b/docs/OpenManus/08_dockersandbox.md index 9b5a0de..9d73405 100644 --- a/docs/OpenManus/08_dockersandbox.md +++ b/docs/OpenManus/08_dockersandbox.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "DockerSandbox" +parent: "OpenManus" +nav_order: 8 +--- + # Chapter 8: DockerSandbox - A Safe Play Area for Code Welcome to Chapter 8! In [Chapter 7: Configuration (Config)](07_configuration__config_.md), we learned how OpenManus manages settings using the `config.toml` file and the `Config` object. We saw settings for the [LLM](01_llm.md), search tools, and something called `[sandbox]`. Now, let's dive into what that sandbox is! diff --git a/docs/OpenManus/09_mcp__model_context_protocol_.md b/docs/OpenManus/09_mcp__model_context_protocol_.md index 5369e13..6b11489 100644 --- a/docs/OpenManus/09_mcp__model_context_protocol_.md +++ b/docs/OpenManus/09_mcp__model_context_protocol_.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "MCP (Model Context Protocol)" +parent: "OpenManus" +nav_order: 9 +--- + # Chapter 9: MCP (Model Context Protocol) Welcome to the final chapter of our core concepts tutorial! In [Chapter 8: DockerSandbox](08_dockersandbox.md), we saw how OpenManus can safely run code in an isolated environment. Now, let's explore a powerful way to extend your agent's capabilities *without* changing its internal code: the **Model Context Protocol (MCP)**. diff --git a/docs/Pydantic Core/01_basemodel.md b/docs/Pydantic Core/01_basemodel.md index 8f8aa25..7af7875 100644 --- a/docs/Pydantic Core/01_basemodel.md +++ b/docs/Pydantic Core/01_basemodel.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "BaseModel" +parent: "Pydantic Core" +nav_order: 1 +--- + # Chapter 1: BaseModel - Your Data Blueprint Welcome to the Pydantic tutorial! We're excited to guide you through the powerful features of Pydantic, starting with the absolute core concept: `BaseModel`. diff --git a/docs/Pydantic Core/02_fields__fieldinfo___field_function_.md b/docs/Pydantic Core/02_fields__fieldinfo___field_function_.md index 42d8386..0841c5b 100644 --- a/docs/Pydantic Core/02_fields__fieldinfo___field_function_.md +++ b/docs/Pydantic Core/02_fields__fieldinfo___field_function_.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "Fields (FieldInfo & Field function)" +parent: "Pydantic Core" +nav_order: 2 +--- + # Chapter 2: Customizing Your Blueprint's Rooms - Fields In [Chapter 1: BaseModel - Your Data Blueprint](01_basemodel.md), we learned how `BaseModel` acts like a blueprint for our data, defining the expected structure and types using simple Python type hints. We saw how Pydantic uses this blueprint to parse, validate, and serialize data. diff --git a/docs/Pydantic Core/03_configuration__configdict___configwrapper_.md b/docs/Pydantic Core/03_configuration__configdict___configwrapper_.md index ab0c2de..962765e 100644 --- a/docs/Pydantic Core/03_configuration__configdict___configwrapper_.md +++ b/docs/Pydantic Core/03_configuration__configdict___configwrapper_.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "Configuration (ConfigDict & ConfigWrapper)" +parent: "Pydantic Core" +nav_order: 3 +--- + # Chapter 3: Configuring Your Blueprint - Model Settings In [Chapter 1](01_basemodel.md), we learned about `BaseModel` as our data blueprint, and in [Chapter 2](02_fields__fieldinfo___field_function_.md), we saw how `Field()` lets us add specific notes (like defaults or aliases) to individual rooms (fields) on that blueprint. diff --git a/docs/Pydantic Core/04_custom_logic__decorators___annotated_helpers_.md b/docs/Pydantic Core/04_custom_logic__decorators___annotated_helpers_.md index e7107a6..eec2954 100644 --- a/docs/Pydantic Core/04_custom_logic__decorators___annotated_helpers_.md +++ b/docs/Pydantic Core/04_custom_logic__decorators___annotated_helpers_.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "Custom Logic (Decorators & Annotated Helpers)" +parent: "Pydantic Core" +nav_order: 4 +--- + # Chapter 4: Custom Logic (Decorators & Annotated Helpers) In [Chapter 3: Configuration (ConfigDict / ConfigWrapper)](03_configuration__configdict___configwrapper_.md), we learned how to set global rules for our data blueprints using `model_config`. But what if we need more specific, custom rules or transformations that go beyond simple settings? diff --git a/docs/Pydantic Core/05_core_schema___validation_serialization.md b/docs/Pydantic Core/05_core_schema___validation_serialization.md index 4cf3787..2ab2a31 100644 --- a/docs/Pydantic Core/05_core_schema___validation_serialization.md +++ b/docs/Pydantic Core/05_core_schema___validation_serialization.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "Core Schema & Validation/Serialization" +parent: "Pydantic Core" +nav_order: 5 +--- + # Chapter 5: Core Schema & Validation/Serialization In the previous chapters, we've seen how to define data structures using [BaseModel](01_basemodel.md), customize fields with [Field()](02_fields__fieldinfo___field_function_.md), set model-wide behavior with [Configuration](03_configuration__configdict___configwrapper_.md), and even add [Custom Logic](04_custom_logic__decorators___annotated_helpers_.md) using decorators. You might be wondering: how does Pydantic take all these Python definitions and use them to perform such fast and reliable validation and serialization? diff --git a/docs/Pydantic Core/06_typeadapter.md b/docs/Pydantic Core/06_typeadapter.md index 2320d52..a7cd45f 100644 --- a/docs/Pydantic Core/06_typeadapter.md +++ b/docs/Pydantic Core/06_typeadapter.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "TypeAdapter" +parent: "Pydantic Core" +nav_order: 6 +--- + # Chapter 6: TypeAdapter - Your Universal Data Handler Welcome to the final chapter of our Pydantic Core tutorial! In [Chapter 5: Core Schema & Validation/Serialization](05_core_schema___validation_serialization.md), we dove deep into how Pydantic uses the `CoreSchema` and the `pydantic-core` engine to efficiently validate and serialize data for your `BaseModel` classes. diff --git a/docs/Requests/01_functional_api.md b/docs/Requests/01_functional_api.md index 55132e3..fb9149e 100644 --- a/docs/Requests/01_functional_api.md +++ b/docs/Requests/01_functional_api.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "Functional API" +parent: "Requests" +nav_order: 1 +--- + # Chapter 1: The Simplest Way - The Functional API Welcome to the world of `Requests`! If you need to get information from a website or interact with a web service using Python, `Requests` is your friendly helper. diff --git a/docs/Requests/02_request___response_models.md b/docs/Requests/02_request___response_models.md index 454c783..85b0eb9 100644 --- a/docs/Requests/02_request___response_models.md +++ b/docs/Requests/02_request___response_models.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "Request & Response Models" +parent: "Requests" +nav_order: 2 +--- + # Chapter 2: What Happens When You Order? Request & Response Models In [Chapter 1: The Simplest Way - The Functional API](01_functional_api.md), we saw how easy it is to fetch a webpage or send data using simple functions like `requests.get()` and `requests.post()`. We also noticed that these functions return something called a `Response` object. diff --git a/docs/Requests/03_session.md b/docs/Requests/03_session.md index 44ba47f..75549de 100644 --- a/docs/Requests/03_session.md +++ b/docs/Requests/03_session.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "Session" +parent: "Requests" +nav_order: 3 +--- + # Chapter 3: Remembering Things - The Session Object In [Chapter 1](01_functional_api.md), we learned the easiest way to make web requests using functions like `requests.get()`. In [Chapter 2](02_request___response_models.md), we looked at the `Request` and `Response` objects that structure our communication with web servers. diff --git a/docs/Requests/04_cookie_jar.md b/docs/Requests/04_cookie_jar.md index 5fe4f51..d28a862 100644 --- a/docs/Requests/04_cookie_jar.md +++ b/docs/Requests/04_cookie_jar.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "Cookie Jar" +parent: "Requests" +nav_order: 4 +--- + # Chapter 4: The Cookie Jar - Remembering Website Visits In [Chapter 3: Remembering Things - The Session Object](03_session.md), we saw how `Session` objects are super useful for making multiple requests to the same website. A big reason they work so well is that they automatically remember **cookies** sent by the server, just like your web browser does. diff --git a/docs/Requests/05_authentication_handlers.md b/docs/Requests/05_authentication_handlers.md index df4b35d..b860348 100644 --- a/docs/Requests/05_authentication_handlers.md +++ b/docs/Requests/05_authentication_handlers.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "Authentication Handlers" +parent: "Requests" +nav_order: 5 +--- + # Chapter 5: Authentication Handlers - Showing Your ID Card In [Chapter 4: The Cookie Jar](04_cookie_jar.md), we learned how `requests` uses `Session` objects and cookie jars to automatically remember things like login cookies. This is great for websites that use cookies to manage sessions after you log in. diff --git a/docs/Requests/06_exception_hierarchy.md b/docs/Requests/06_exception_hierarchy.md index 5f7ea87..923c5ee 100644 --- a/docs/Requests/06_exception_hierarchy.md +++ b/docs/Requests/06_exception_hierarchy.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "Exception Hierarchy" +parent: "Requests" +nav_order: 6 +--- + # Chapter 6: When Things Go Wrong - The Exception Hierarchy In [Chapter 5: Authentication Handlers](05_authentication_handlers.md), we learned how to prove our identity to websites that require login or API keys. We assumed our requests would work if we provided the correct credentials. diff --git a/docs/Requests/07_transport_adapters.md b/docs/Requests/07_transport_adapters.md index 67467a2..20601ab 100644 --- a/docs/Requests/07_transport_adapters.md +++ b/docs/Requests/07_transport_adapters.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "Transport Adapters" +parent: "Requests" +nav_order: 7 +--- + # Chapter 7: Transport Adapters - Custom Delivery Routes In the previous chapter, [Chapter 6: Exception Hierarchy](06_exception_hierarchy.md), we learned how `requests` signals problems like network errors or bad responses. Most of the time, we rely on the default way `requests` handles sending our requests and managing connections. diff --git a/docs/Requests/08_hook_system.md b/docs/Requests/08_hook_system.md index 55f084a..8cc489d 100644 --- a/docs/Requests/08_hook_system.md +++ b/docs/Requests/08_hook_system.md @@ -1,3 +1,10 @@ +--- +layout: default +title: "Hook System" +parent: "Requests" +nav_order: 8 +--- + # Chapter 8: The Hook System - Setting Up Checkpoints In [Chapter 7: Transport Adapters](07_transport_adapters.md), we saw how to customize the low-level details of *how* requests are sent and connections are managed, like setting custom retry strategies. Transport Adapters give you control over the delivery mechanism itself.