Directory Structure
Relevant source files
The following files were used as context for generating this wiki page:
SeaORM Pro is organized as a Rust workspace that separates core logic, migration tools, administrative configuration, and implementation examples. The project structure is designed to support a full-stack admin panel framework, integrating the SeaORM ORM with a pre-built frontend and a configuration-driven backend.
Sources: Cargo.toml:1-4, README.md:1-10, sea-orm-pro/README.md:1-5
Root Workspace Structure
The project uses a Cargo workspace to manage multiple related crates. The root directory contains the main backend application and orchestrates the library and migration components.
- sea-orm-pro/: A helper library containing core logic for parsing configurations and managing the admin panel backend.
- migration/: Contains database schema definitions and migration scripts.
- src/: The main backend source code, often utilizing the
loco-rsframework for application structure. - pro_admin/: A critical directory containing TOML configuration files that define the admin panel's UI, dashboard, and table views.
- assets/: Target directory for the downloaded admin frontend assets.
- build_tools/: Shell scripts for automation, including frontend acquisition and project scaffolding.
Sources: Cargo.toml:1-3, README.md:50-55, build_tools/download_frontend.sh:5-7, build_tools/scaffold.sh:10-14
Visual Representation of Workspace Relationships
The following diagram illustrates how the different components of the workspace interact and where configurations are stored.
Admin Configuration (pro_admin)
The pro_admin directory is the primary location for customizing the admin interface without writing frontend code. It is structured into specific subdirectories for different types of table views.
| Directory/File | Description |
|---|---|
config.toml | Global site settings (theme, logo, navbar features). |
dashboard.toml | Layout and data sources for the landing dashboard (charts, info cards). |
raw_tables/ | TOML files defining individual table views and field visibility. |
composite_tables/ | Definitions for complex views involving parent-child relationships (e.g., Sales Orders). |
Sources: pro_admin/config.toml:1-15, pro_admin/dashboard.toml:1-15, sea-orm-pro/src/parser.rs:18-45, pro_admin/composite_tables/sales_order.toml:1-15
Library Structure (sea-orm-pro crate)
The sea-orm-pro crate acts as the engine that transforms TOML configurations into JSON for the frontend.
- src/parser.rs: Implements the
ConfigParserwhich walks thepro_admindirectory to aggregate all settings. - src/config.rs: (Inferred from imports) Defines the data structures for
RawTableCfg,CompositeTableCfg, andJsonCfg.
Sources: sea-orm-pro/src/parser.rs:1-10, sea-orm-pro/Cargo.toml:25-30
Config Loading Flow
This sequence shows how the ConfigParser processes the directory structure to serve the API.
Examples and Implementation
The examples/ directory provides reference implementations of the directory structure in different contexts.
- examples/axum_example/: A standalone example showing how to integrate the admin panel with an Axum server.
- api/: Web server logic and route definitions.
- api/static/: CSS and assets (e.g.,
skeleton.css,normalize.css). - entity/: SeaORM entities generated for the example.
- service/: Business logic layer.
Sources: examples/axum_example/Cargo.toml:1-10, examples/axum_example/api/src/lib.rs:50-80, examples/axum_example/api/static/css/skeleton.css:1-20
Build and Scaffolding Tools
The build_tools/ directory contains utilities that manipulate the project structure.
- download_frontend.sh: Automates the creation of the
assets/admindirectory and populates it with the pre-compiled frontend. - scaffold.sh: A script that cleans up the directory structure by removing demo entities, clearing out existing table configurations in
pro_admin/raw_tables, and resetting migrations.
Sources: build_tools/download_frontend.sh:5-15, build_tools/scaffold.sh:5-15
Summary
The SeaORM Pro directory structure is optimized for a configuration-first workflow. Developers maintain their database logic in src/models and migration/, while the administrative interface is managed through declarative TOML files within the pro_admin hierarchy. The use of a Rust workspace ensures that the core parsing logic remains decoupled from the specific web framework implementation.