372b7a2772
This commit represents a major refactoring of our Rhai scripting system, transforming it from a factory-based approach to a more robust system-based architecture with improved hot reloading capabilities. Key Changes: - Renamed package from rhai_factory to rhai_system to better reflect its purpose - Renamed system_factory.rs to factory.rs for consistency and clarity - Implemented support for multiple script files in hot reloading - Added cross-script function calls, allowing functions in one script to call functions in another - Improved file watching to monitor all script files for changes - Enhanced error handling for script compilation failures - Simplified the API with a cleaner create_hot_reloadable_system function - Removed unused modules (error.rs, factory.rs, hot_reload_old.rs, module_cache.rs, relative_resolver.rs) - Updated all tests to work with the new architecture The new architecture: - Uses a System struct that holds references to script paths and provides a clean API - Compiles and merges multiple Rhai script files into a single AST - Automatically detects changes to any script file and recompiles them - Maintains thread safety with proper synchronization primitives - Provides better error messages when scripts fail to compile This refactoring aligns with our BasePathModuleResolver approach for module imports, making the resolution process more predictable and consistent. The hot reload example has been updated to demonstrate the new capabilities, showing how to: 1. Load and execute multiple script files 2. Watch for changes to these files 3. Automatically reload scripts when they change 4. Call functions across different script files All tests are passing, and the example demonstrates the improved functionality. |
||
|---|---|---|
| .. | ||
| components | ||
| src | ||
| Cargo.lock | ||
| Cargo.toml | ||
| main.rhai | ||
| README.md | ||
Base Path Module Resolver Example
This example demonstrates the use of the BasePathModuleResolver for simplifying Rhai script module imports.
Overview
The BasePathModuleResolver provides a more predictable and consistent approach to module resolution by:
- Using a single base path for resolving all module imports
- Eliminating the complexity of resolving imports relative to the importing file
- Requiring all import paths to be specified relative to the base path
Directory Structure
The example follows a hierarchical directory structure:
base_path_imports/
├── components/
│ ├── calendar/
│ │ └── controller/
│ │ └── mock/
│ │ └── calendar_model.rhai
│ ├── common/
│ │ └── utils/
│ │ ├── date_utils.rhai
│ │ └── string_utils.rhai
│ └── website/
│ └── controller/
│ └── mock/
│ └── website_model.rhai
├── main.rhai
└── src/
└── main.rs
Key Components
1. BasePathModuleResolver
Located in rhai_factory/src/relative_resolver.rs, this resolver simplifies module imports by:
- Taking a base path during initialization
- Resolving all module imports relative to this base path
- Providing clear logging of the resolution process
2. Utility Modules
Common utility functions are organized in the components/common/utils/ directory:
string_utils.rhai: Basic string manipulation functionsdate_utils.rhai: Date formatting and validation functions
3. Component-Specific Modules
Component-specific functionality is organized in dedicated directories:
components/calendar/controller/mock/calendar_model.rhai: Calendar event creation and validationcomponents/website/controller/mock/website_model.rhai: Website page creation and validation
4. Main Script
The main.rhai script demonstrates importing and using modules from different components.
Running the Example
To run the example:
cd rhai_factory/examples/base_path_imports
cargo run
Key Benefits
- Simplified Imports: All imports are relative to a single base path
- Predictable Resolution: No need to calculate relative paths between files
- Cleaner Code: No need for complex "../../../" style paths
- Better Organization: Encourages a modular, component-based structure
- Improved Debugging: Clear logging of the module resolution process
Implementation Details
The example demonstrates:
- Setting up the
BasePathModuleResolverwith a base path - Importing modules using paths relative to the base path
- Using utility functions from common modules
- Creating component-specific functionality that leverages common utilities