Update: adding comments to dispatcher
This commit is contained in:
parent
7dfa47cfe9
commit
46824efee0
4 changed files with 909 additions and 0 deletions
229
.cursorrules
Normal file
229
.cursorrules
Normal file
|
@ -0,0 +1,229 @@
|
|||
@Codebase
|
||||
|
||||
The name of our company is Protevus
|
||||
The name of our project is Platform
|
||||
Protevus = Laravel and Platform = Illuminate
|
||||
Our Development Langauge is Dart
|
||||
Our cross-platform UI Kit is Flutter
|
||||
Our Implementation is based on Angel3
|
||||
Our Deployment Target are Windows, MacOS, Linux, iOS, Android, Web, IoT and Edge Devices
|
||||
|
||||
Protevus Aims to bring a complete Laravel experience to Dart, and Flutter with a truely Unified Full Stack Experience. We aim to mature the platform to support cross-platform development of complex government, military, and enterprise applications.
|
||||
|
||||
Our 10 Step Development Lifecycle is as follows: We use a hybrid mix of Interface Driven Development, Test Driven Development and AI Software Engineer Agents to assist in generating efficient and reliable code while also providing help with other task like code reviews, documentation, and testing. We call this approach IDDA or Integrated Development Design and AI.
|
||||
|
||||
1. Research - Research the requirements and specifications of the project.
|
||||
2. Identify - Identify the key components and technologies that are needed to build the project. (use opensource)
|
||||
3. Transform - Transform the requirements and specifications from the code to a langauge agnostic abstract contract (YAML)
|
||||
4. Inform - Use the abstract contracts to inform the design of the system and the components.
|
||||
5. Generate - Use AI to generate the initial code based on the abstract contracts.
|
||||
6. Implement - Implement the code in the codebase.
|
||||
7. Test - Test the code to ensure it meets the requirements and specifications.
|
||||
8. Iterate - Iterate the code to improve the design and implementation.
|
||||
9. Review - Review the code to ensure it meets the requirements and specifications.
|
||||
10. Release - Release the code to the public.
|
||||
|
||||
Or RITIGITIRR pronounced Rite-Ghee-Tee-Ree
|
||||
|
||||
The we wash rinse and repeat for each project. When we are done we have a fully functional and robust implementation of the requirements and specifications we will still follow this pattern for enhancements, bug fixes, and new features.
|
||||
|
||||
The API Specifications are in inbox/spec_packagename
|
||||
The Concrete Implementations are in inbox/src_packagename
|
||||
|
||||
The directory structure that matters most is as follows: RITIGITIRR
|
||||
|
||||
archieved/ = old versions of the codebase
|
||||
config/ = configuration files
|
||||
core/ = core packages required for minimal server functionality (Platform Zero Server)
|
||||
docs/ = documentation
|
||||
examples/ = example applications demonstrating using the Platform API
|
||||
inbox/ = packages that are being worked on
|
||||
packages/ = packages that are not ready for use (Original Angel3 Packages)
|
||||
sandbox/ = packages that are being vetted for forked integration ready for use (Experimental Packages)
|
||||
stubs/ = stubs for packages that can be used as starter templates jumpstarting development
|
||||
utils/ = utility scripts
|
||||
wspace/ = workspace for development
|
||||
|
||||
Protevus Platform is a hard-fork of Angel3 that is being refactored and rebranded to be Protevus Platform
|
||||
For now all references to Angel3 remain the same, but in the future we will be changing them to Protevus or Platform
|
||||
You must always refer to the project as Platform, not Protevus or Angel3
|
||||
|
||||
You must always prefer leveraging existing sanctioned angel3 packages as dependencies where possible as most of them will be replace and can't be relied on initially.
|
||||
|
||||
You must always prefer leveraging existing standard dart packages as dependencies where possible
|
||||
You will always prefer leveraging any packages that we can from pub.dev or github.com dart/flutter ecosystem
|
||||
|
||||
Our goal is to reimplement the laravel illuminate packages as angel3 packages in short bringing Laravel to Dart
|
||||
Our goal is to reach feature parity with the illuminate api so we must adhere to the specifications of laravel's api as we reimplement the illuminate packages
|
||||
|
||||
We will not reimplement any packages that are not part of laravel, such as symfony packages, or any other packages that are not part of the laravel framework as our goal is to have pure dart implementations so we must find packages in the dart ecosystem where possible or create the feature in dart.
|
||||
|
||||
We will not be re-implementing some features of laravel that would require reinventing wheels, for example angel3's server system is more then sufficiant and consist of the following angel3 packages which we will be initally keeping. Container, Framework, Route Http_Exception, Mock_Request, Modal. All other Illuminate packages will be reimplemented in dart. This list of keepers may change as we begin our phases of development.
|
||||
|
||||
You must always take the following points into consderation when planning and executing your task.
|
||||
|
||||
1. Dart and Flutter ecosystem awareness:
|
||||
- Stay updated with the latest Dart language features and best practices.
|
||||
- Consider Flutter compatibility for components that might be used in mobile/web applications.
|
||||
- Utilize popular Dart packages when appropriate, but be mindful of adding unnecessary dependencies.
|
||||
|
||||
2. Performance considerations:
|
||||
- Implement benchmarking tools to compare performance with both Laravel and the original Angel3.
|
||||
- Use Dart's profiling tools to identify and optimize bottlenecks.
|
||||
- Consider implementing lazy loading and deferred initialization where appropriate.
|
||||
|
||||
3. Asynchronous programming:
|
||||
- Leverage Dart's async/await and Future-based programming extensively.
|
||||
- Implement proper error handling and cancellation for asynchronous operations.
|
||||
- Consider using Streams for reactive programming where appropriate.
|
||||
|
||||
4. Code style and structure:
|
||||
- Follow Dart's official style guide and linting rules.
|
||||
- Implement consistent error handling and logging practices across all packages.
|
||||
- Use Dart's strong typing system to its full potential, including generics and type inference.
|
||||
|
||||
5. Testing strategy:
|
||||
- Implement both unit and integration tests for all components.
|
||||
- Use mock objects and dependency injection to facilitate easier testing.
|
||||
- Implement property-based testing for complex algorithms or data structures.
|
||||
|
||||
6. Documentation:
|
||||
- Use Dart's documentation comments extensively.
|
||||
- Provide examples in documentation for all public APIs.
|
||||
- Create architecture decision records (ADRs) for significant design choices.
|
||||
|
||||
7. Internationalization and localization:
|
||||
- Design with i18n in mind from the start.
|
||||
- Use Dart's intl package for formatting dates, numbers, and plurals.
|
||||
|
||||
8. Error handling and logging:
|
||||
- Implement a consistent error handling strategy across all packages.
|
||||
- Create custom exception classes where appropriate.
|
||||
- Implement structured logging with different log levels.
|
||||
|
||||
9. Security:
|
||||
- Implement security best practices, including input validation, output encoding, and CSRF protection.
|
||||
- Use secure random number generation for cryptographic operations.
|
||||
- Implement rate limiting and throttling mechanisms.
|
||||
|
||||
10. Dependency management:
|
||||
- Use Dart's pub tool effectively for package management.
|
||||
- Consider implementing a monorepo structure for managing multiple packages.
|
||||
|
||||
11. Compatibility layers:
|
||||
- Implement compatibility layers or wrappers to ease migration from Angel3 to the new framework.
|
||||
- Provide migration scripts or tools where possible.
|
||||
|
||||
12. Extensibility:
|
||||
- Design components with extensibility in mind, allowing for easy customization and overriding of default behaviors.
|
||||
- Implement plugin systems where appropriate.
|
||||
|
||||
13. Configuration:
|
||||
- Implement a flexible configuration system that supports different environments (development, testing, production).
|
||||
- Support both file-based and environment variable-based configuration.
|
||||
|
||||
14. CLI tools:
|
||||
- Develop CLI tools to assist in common development tasks (e.g., generating boilerplate code, running migrations).
|
||||
- Ensure CLI tools are cross-platform compatible.
|
||||
|
||||
15. Database abstraction:
|
||||
- Implement database migrations and seeders.
|
||||
- Support multiple database systems, including NoSQL databases.
|
||||
|
||||
16. API design:
|
||||
- Follow RESTful principles when designing APIs.
|
||||
- Consider implementing GraphQL support.
|
||||
|
||||
17. Caching strategies:
|
||||
- Implement various caching mechanisms (in-memory, file-based, distributed).
|
||||
- Provide cache invalidation strategies.
|
||||
|
||||
18. Scalability:
|
||||
- Design components with horizontal scalability in mind.
|
||||
- Implement support for distributed systems and microservices architecture.
|
||||
|
||||
19. Metrics and monitoring:
|
||||
- Implement instrumentation for gathering metrics.
|
||||
- Provide hooks for integrating with monitoring systems.
|
||||
|
||||
20. Dependency injection:
|
||||
- Implement a robust dependency injection system.
|
||||
- Support both constructor and property injection.
|
||||
|
||||
21. Reflection and metadata:
|
||||
- Utilize Dart's reflection capabilities where appropriate.
|
||||
- Implement custom metadata annotations for declarative programming.
|
||||
|
||||
22. Error reporting:
|
||||
- Implement integration with error reporting services (e.g., Sentry).
|
||||
- Provide detailed stack traces and context for errors.
|
||||
|
||||
23. Code generation:
|
||||
- Utilize Dart's build system for code generation where appropriate.
|
||||
- Implement source code generators for repetitive tasks.
|
||||
|
||||
24. Versioning:
|
||||
- Follow semantic versioning principles.
|
||||
- Maintain a detailed changelog.
|
||||
|
||||
25. Community engagement:
|
||||
- Set up issue templates and contribution guidelines on GitHub.
|
||||
- Implement a code of conduct for the project.
|
||||
|
||||
26. Null Safety
|
||||
- Implement sound null safety throughout the entire codebase.
|
||||
- Utilize Dart's null safety features, including:
|
||||
- Nullable and non-nullable types
|
||||
- Late variables
|
||||
- Null-aware operators
|
||||
- Perform null checks where necessary and provide clear documentation on nullability for all public APIs.
|
||||
- Use the `required` keyword for named parameters that must not be null.
|
||||
- Leverage the `?`, `!`, and `??` operators appropriately to handle potential null values.
|
||||
- Implement proper error handling for cases where null values are unexpected.
|
||||
- When interfacing with external code or APIs that are not null-safe:
|
||||
- Use the `dynamic` type or appropriate cast operations cautiously
|
||||
- Utilize the `Never` type for functions that never return normally (i.e., always throw an exception or loop forever).
|
||||
- Consider using the `late` keyword for variables that are initialized after their declaration but before they're used.
|
||||
- When working with collections:
|
||||
- Prefer using nullable item types (e.g., `List<String?>`) over nullable collections (e.g., `List<String>?`) where appropriate
|
||||
- Use static analysis tools to catch potential null safety issues early in the development process.
|
||||
- When migrating existing code:
|
||||
- Use the Dart migration tool
|
||||
- Carefully review all changes
|
||||
- Educate contributors on null safety best practices and include null safety checks in code review processes.
|
||||
|
||||
Here are some notes that you should always keep in mind when working with the project
|
||||
|
||||
Here's the content formatted in Markdown:
|
||||
|
||||
## General Guidelines
|
||||
|
||||
- Always consider the idiomatic Dart approach when implementing Laravel features.
|
||||
- Maintain compatibility with existing Angel3 applications where possible.
|
||||
- Prioritize performance and scalability in all implementations.
|
||||
- Write comprehensive tests for each component, aiming for high code coverage.
|
||||
- Document all public APIs and provide usage examples.
|
||||
- Consider cross-platform compatibility (server, web, mobile) where applicable.
|
||||
- Keep security as a top priority, especially when implementing authentication and encryption features.
|
||||
- Regularly refactor and optimize code as the project progresses.
|
||||
- Engage with the Angel3 community for feedback and contributions throughout the development process.
|
||||
|
||||
## Advanced Implementation Considerations
|
||||
|
||||
- When implementing advanced features like Telescope or Dusk, consider how they can be adapted to work well in a Dart ecosystem.
|
||||
- Pay special attention to how Facades and Macroable traits can be implemented in Dart, as these are core to Laravel's flexibility but may not have direct equivalents in Dart.
|
||||
- For packages like Scout and Passport, research Dart-specific best practices for implementing search and OAuth2 functionalities.
|
||||
- When working on Blade-like templating, consider how to balance between staying close to Blade's syntax and leveraging Dart's language features.
|
||||
|
||||
## Dart-Specific Considerations
|
||||
|
||||
- Always consider the implications of Dart's strong typing when implementing dynamic features from Laravel.
|
||||
- Look for opportunities to leverage Dart's unique features, such as isolates for concurrency, where appropriate.
|
||||
|
||||
This is the project roadmap for the Dart version of Laravel, which aims to bring the power and flexibility of Laravel to the Dart ecosystem. The roadmap is divided into several phases, each focusing on implementing specific Laravel features in Dart. Please use it to your advantage and contribute to the project's success.
|
||||
|
||||
Certainly! I'll combine everything into a comprehensive roadmap, including descriptions for each package in Markdown format. This will serve as a complete guide for the AI engineer.
|
||||
|
||||
The Project Road Map is in @Roadmap
|
||||
|
||||
You now have access to all the information that all team members need to start working on the project.
|
3
.gitignore
vendored
3
.gitignore
vendored
|
@ -80,3 +80,6 @@ logs/
|
|||
server_log.txt
|
||||
backup/
|
||||
|
||||
# temp
|
||||
inbox/
|
||||
|
||||
|
|
|
@ -12,6 +12,10 @@ import 'handler.dart';
|
|||
import 'batch.dart';
|
||||
import 'chain.dart';
|
||||
|
||||
/// A class that handles dispatching and processing of commands.
|
||||
///
|
||||
/// This dispatcher supports both synchronous and asynchronous command execution,
|
||||
/// as well as queueing commands for later processing.
|
||||
class Dispatcher implements QueueingDispatcher {
|
||||
final Container container;
|
||||
final EventBus _eventBus;
|
||||
|
@ -19,6 +23,9 @@ class Dispatcher implements QueueingDispatcher {
|
|||
final MQClient _queue;
|
||||
final Map<Type, Type> _handlers = {};
|
||||
|
||||
/// Creates a new [Dispatcher] instance.
|
||||
///
|
||||
/// [container] is used for dependency injection and to retrieve necessary services.
|
||||
Dispatcher(this.container)
|
||||
: _eventBus = container.make<EventBus>(),
|
||||
_commandSubject = BehaviorSubject<Command>(),
|
||||
|
@ -26,6 +33,9 @@ class Dispatcher implements QueueingDispatcher {
|
|||
_setupCommandProcessing();
|
||||
}
|
||||
|
||||
/// Sets up the command processing pipeline.
|
||||
///
|
||||
/// This method initializes the stream that processes commands and emits events.
|
||||
void _setupCommandProcessing() {
|
||||
_commandSubject
|
||||
.flatMap((command) => Stream.fromFuture(_processCommand(command))
|
||||
|
@ -37,6 +47,12 @@ class Dispatcher implements QueueingDispatcher {
|
|||
});
|
||||
}
|
||||
|
||||
/// Dispatches a command for execution.
|
||||
///
|
||||
/// If the command implements [ShouldQueue], it will be dispatched to a queue.
|
||||
/// Otherwise, it will be executed immediately.
|
||||
///
|
||||
/// [command] is the command to be dispatched.
|
||||
@override
|
||||
Future<dynamic> dispatch(Command command) {
|
||||
if (command is ShouldQueue) {
|
||||
|
@ -46,6 +62,10 @@ class Dispatcher implements QueueingDispatcher {
|
|||
}
|
||||
}
|
||||
|
||||
/// Dispatches a command for immediate execution.
|
||||
///
|
||||
/// [command] is the command to be executed.
|
||||
/// [handler] is an optional specific handler for the command.
|
||||
@override
|
||||
Future<dynamic> dispatchNow(Command command, [Handler? handler]) {
|
||||
final completer = Completer<dynamic>();
|
||||
|
@ -66,6 +86,9 @@ class Dispatcher implements QueueingDispatcher {
|
|||
return completer.future;
|
||||
}
|
||||
|
||||
/// Processes a command by finding and executing its appropriate handler.
|
||||
///
|
||||
/// [command] is the command to be processed.
|
||||
Future<dynamic> _processCommand(Command command) async {
|
||||
final handlerType = _handlers[command.runtimeType];
|
||||
if (handlerType != null) {
|
||||
|
@ -76,6 +99,9 @@ class Dispatcher implements QueueingDispatcher {
|
|||
}
|
||||
}
|
||||
|
||||
/// Dispatches a command to a queue for later processing.
|
||||
///
|
||||
/// [command] is the command to be queued.
|
||||
@override
|
||||
Future<dynamic> dispatchToQueue(Command command) async {
|
||||
final message = Message(
|
||||
|
@ -93,27 +119,45 @@ class Dispatcher implements QueueingDispatcher {
|
|||
return message.id;
|
||||
}
|
||||
|
||||
/// Dispatches a command synchronously.
|
||||
///
|
||||
/// This is an alias for [dispatchNow].
|
||||
///
|
||||
/// [command] is the command to be executed.
|
||||
/// [handler] is an optional specific handler for the command.
|
||||
@override
|
||||
Future<dynamic> dispatchSync(Command command, [Handler? handler]) {
|
||||
return dispatchNow(command, handler);
|
||||
}
|
||||
|
||||
/// Finds a batch by its ID.
|
||||
///
|
||||
/// [batchId] is the ID of the batch to find.
|
||||
@override
|
||||
Future<Batch?> findBatch(String batchId) async {
|
||||
// Implement batch finding logic
|
||||
throw UnimplementedError();
|
||||
}
|
||||
|
||||
/// Creates a new pending batch of commands.
|
||||
///
|
||||
/// [commands] is the list of commands to be included in the batch.
|
||||
@override
|
||||
PendingBatch batch(List<Command> commands) {
|
||||
return PendingBatch(this, commands);
|
||||
}
|
||||
|
||||
/// Creates a new pending chain of commands.
|
||||
///
|
||||
/// [commands] is the list of commands to be included in the chain.
|
||||
@override
|
||||
PendingChain chain(List<Command> commands) {
|
||||
return PendingChain(this, commands);
|
||||
}
|
||||
|
||||
/// Applies a list of pipes to the command processing pipeline.
|
||||
///
|
||||
/// [pipes] is the list of pipes to be applied.
|
||||
@override
|
||||
Dispatcher pipeThrough(List<Pipe> pipes) {
|
||||
_commandSubject.transform(
|
||||
|
@ -130,12 +174,18 @@ class Dispatcher implements QueueingDispatcher {
|
|||
return this;
|
||||
}
|
||||
|
||||
/// Maps command types to their respective handler types.
|
||||
///
|
||||
/// [handlers] is a map where keys are command types and values are handler types.
|
||||
@override
|
||||
Dispatcher map(Map<Type, Type> handlers) {
|
||||
_handlers.addAll(handlers);
|
||||
return this;
|
||||
}
|
||||
|
||||
/// Dispatches a command to be executed after the current request-response cycle.
|
||||
///
|
||||
/// [command] is the command to be dispatched after the response.
|
||||
@override
|
||||
void dispatchAfterResponse(Command command) {
|
||||
final message = Message(
|
||||
|
|
627
s
Normal file
627
s
Normal file
|
@ -0,0 +1,627 @@
|
|||
# Comprehensive Roadmap: Porting Laravel Illuminate to Dart (Angel3-based)
|
||||
|
||||
## Phase 0: Forking and Preparing Angel3
|
||||
|
||||
### 0.1 Fork Angel3
|
||||
- Create a new repository based on Angel3
|
||||
- Update package names and namespaces
|
||||
- Considerations:
|
||||
- Maintain compatibility with existing Angel3 apps
|
||||
- Plan for gradual migration of Angel3 users
|
||||
|
||||
### 0.2 Set Up Development Environment
|
||||
- Configure CI/CD pipeline
|
||||
- Set up testing framework
|
||||
- Establish coding standards and linting rules
|
||||
|
||||
### 0.3 Audit Existing Angel3 Packages
|
||||
- Identify packages to keep, modify, or replace
|
||||
- Create a compatibility layer for existing Angel3 apps
|
||||
|
||||
## Phase 1: Core Utilities and Infrastructure
|
||||
|
||||
### 1.1 Support
|
||||
**Description**: Provides a set of utility functions and helper methods used throughout the framework.
|
||||
|
||||
- **Dependencies**: None
|
||||
- **Dart packages**: dart:core, collection, quiver
|
||||
- **Angel3 equivalent**: partial (angel3_framework)
|
||||
- **Tasks**:
|
||||
- Implement string helpers
|
||||
- Create array manipulation utilities
|
||||
- Develop common utility functions
|
||||
- **Considerations**:
|
||||
- Leverage Dart's built-in capabilities
|
||||
- Ensure compatibility with existing Angel3 utilities
|
||||
|
||||
### 1.2 Contracts
|
||||
**Description**: Defines a set of interfaces that form the core of the framework, ensuring loose coupling and consistent API design.
|
||||
|
||||
- **Dependencies**: Support
|
||||
- **Dart packages**: None (custom interfaces)
|
||||
- **Angel3 equivalent**: partial (angel3_framework)
|
||||
- **Tasks**:
|
||||
- Define core interfaces for the framework
|
||||
- Adapt Laravel contracts to Dart
|
||||
- **Considerations**:
|
||||
- Account for Dart language features (e.g., mixins)
|
||||
- Ensure compatibility with Angel3's existing interfaces
|
||||
|
||||
### 1.3 Container
|
||||
**Description**: Implements a powerful dependency injection container for managing class dependencies and performing dependency injection.
|
||||
|
||||
- **Dependencies**: Support
|
||||
- **Dart packages**: get_it, injectable
|
||||
- **Angel3 equivalent**: angel3_container
|
||||
- **Tasks**:
|
||||
- Implement service container
|
||||
- Support auto-wiring and dependency resolution
|
||||
- Implement container events and extensions
|
||||
- **Considerations**:
|
||||
- Ensure compatibility with existing Angel3 DI system
|
||||
- Optimize for performance in resolving dependencies
|
||||
|
||||
### 1.4 Config
|
||||
**Description**: Manages application configuration, supporting various config formats and environment-specific settings.
|
||||
|
||||
- **Dependencies**: Support, Contracts
|
||||
- **Dart packages**: yaml, json_annotation
|
||||
- **Angel3 equivalent**: angel3_configuration
|
||||
- **Tasks**:
|
||||
- Implement configuration management system
|
||||
- Support YAML and JSON formats
|
||||
- Implement dot notation access for nested configs
|
||||
- **Considerations**:
|
||||
- Allow for environment-specific configurations
|
||||
- Implement caching for performance
|
||||
|
||||
### 1.5 Filesystem
|
||||
**Description**: Provides a powerful filesystem abstraction layer, supporting both local and cloud storage systems.
|
||||
|
||||
- **Dependencies**: Support, Contracts
|
||||
- **Dart packages**: dart:io, path
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement file system abstraction
|
||||
- Support local and cloud storage providers
|
||||
- Implement file streaming capabilities
|
||||
- **Considerations**:
|
||||
- Ensure cross-platform compatibility
|
||||
- Implement asynchronous operations for better performance
|
||||
|
||||
## Phase 2: Data Management and Caching
|
||||
|
||||
### 2.1 Cache
|
||||
**Description**: Provides a unified API for various caching systems, supporting multiple cache stores and tagging.
|
||||
|
||||
- **Dependencies**: Support, Contracts
|
||||
- **Dart packages**: hive, shared_preferences
|
||||
- **Angel3 equivalent**: angel3_cache
|
||||
- **Tasks**:
|
||||
- Implement multi-store caching system
|
||||
- Support in-memory, file, and database caching
|
||||
- Implement cache tagging and invalidation
|
||||
- **Considerations**:
|
||||
- Ensure thread-safety for concurrent access
|
||||
- Implement distributed caching capabilities
|
||||
|
||||
### 2.2 Collections
|
||||
**Description**: Provides a fluent, convenient wrapper for working with arrays of data, offering numerous helpful methods for manipulating and interacting with collections.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Macroable
|
||||
- **Dart packages**: dart:collection, collection
|
||||
- **Angel3 equivalent**: Partial (in angel3_framework)
|
||||
- **Tasks**:
|
||||
- Enhance collection manipulation capabilities
|
||||
- Implement Laravel-style collection methods
|
||||
- Consider lazy evaluation for performance
|
||||
- **Considerations**:
|
||||
- Optimize for performance with large datasets
|
||||
- Implement method chaining for fluent API
|
||||
|
||||
### 2.3 Database
|
||||
**Description**: Provides a database abstraction layer supporting various database systems with a fluent query builder.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Events
|
||||
- **Dart packages**: sqflite, postgres, mysql1
|
||||
- **Angel3 equivalent**: angel3_orm
|
||||
- **Tasks**:
|
||||
- Implement database abstraction layer
|
||||
- Support multiple database systems
|
||||
- Implement query builder
|
||||
- **Considerations**:
|
||||
- Ensure compatibility with existing Angel3 ORM
|
||||
- Implement connection pooling for performance
|
||||
|
||||
### 2.4 Eloquent (ORM)
|
||||
**Description**: An advanced implementation of the ActiveRecord pattern, providing an expressive ORM for database interaction.
|
||||
|
||||
- **Dependencies**: Database, Support, Container, Contracts, Events, Pagination
|
||||
- **Dart packages**: drift, floor
|
||||
- **Angel3 equivalent**: angel3_orm
|
||||
- **Tasks**:
|
||||
- Implement Active Record ORM
|
||||
- Support relationships, eager loading, and model events
|
||||
- Implement query scopes and attribute casting
|
||||
- **Considerations**:
|
||||
- Balance between feature parity with Laravel and Dart idioms
|
||||
- Optimize for performance, especially with large datasets
|
||||
|
||||
### 2.5 Pagination
|
||||
**Description**: Provides convenient methods for paginating database results or large datasets.
|
||||
|
||||
- **Dependencies**: Support, Contracts
|
||||
- **Dart packages**: Custom implementation
|
||||
- **Angel3 equivalent**: Partial (in angel3_orm)
|
||||
- **Tasks**:
|
||||
- Implement database result pagination
|
||||
- Support cursor-based and offset-based pagination
|
||||
- Implement serialization for API responses
|
||||
- **Considerations**:
|
||||
- Ensure efficiency with large datasets
|
||||
- Implement support for various front-end frameworks
|
||||
|
||||
## Phase 3: HTTP and Routing
|
||||
|
||||
### 3.1 Http
|
||||
**Description**: Provides a powerful HTTP client and server implementation, including middleware support and content negotiation.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Events, Filesystem, Log
|
||||
- **Dart packages**: http, dio
|
||||
- **Angel3 equivalent**: angel3_http
|
||||
- **Tasks**:
|
||||
- Enhance HTTP client and server capabilities
|
||||
- Implement middleware pipeline
|
||||
- Support content negotiation and file uploads
|
||||
- **Considerations**:
|
||||
- Ensure backward compatibility with Angel3 HTTP handling
|
||||
- Implement HTTP/2 support
|
||||
|
||||
### 3.2 Session
|
||||
**Description**: Provides a unified API for storing and retrieving user session data across various backends.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Cookie, Filesystem
|
||||
- **Dart packages**: shared_preferences, hive
|
||||
- **Angel3 equivalent**: angel3_session
|
||||
- **Tasks**:
|
||||
- Implement session management
|
||||
- Support multiple session drivers (file, database, cache)
|
||||
- Implement session encryption and flash data
|
||||
- **Considerations**:
|
||||
- Ensure data security and encryption
|
||||
- Implement efficient session garbage collection
|
||||
|
||||
### 3.3 Cookie
|
||||
**Description**: Provides a convenient interface for creating and managing HTTP cookies.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Encryption
|
||||
- **Dart packages**: http (for web)
|
||||
- **Angel3 equivalent**: Partial (in angel3_http)
|
||||
- **Tasks**:
|
||||
- Implement cookie handling
|
||||
- Support secure cookies and cookie encryption
|
||||
- Implement cookie jar for HTTP clients
|
||||
- **Considerations**:
|
||||
- Ensure compliance with cookie standards and best practices
|
||||
- Implement support for SameSite attribute
|
||||
|
||||
### 3.4 Routing
|
||||
**Description**: Provides a powerful routing system for handling HTTP requests, including route groups, model binding, and subdomain routing.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Http, Events
|
||||
- **Dart packages**: Custom implementation (building on Angel3's route)
|
||||
- **Angel3 equivalent**: angel3_route
|
||||
- **Tasks**:
|
||||
- Enhance routing capabilities
|
||||
- Implement route groups, named routes, and route model binding
|
||||
- Support subdomain routing
|
||||
- **Considerations**:
|
||||
- Maintain compatibility with existing Angel3 routes
|
||||
- Implement route caching for performance
|
||||
|
||||
### 3.5 Middleware
|
||||
**Description**: Provides a mechanism for filtering HTTP requests entering your application.
|
||||
|
||||
- **Dependencies**: Support, Contracts
|
||||
- **Dart packages**: shelf (for server-side)
|
||||
- **Angel3 equivalent**: Partial (in angel3_framework)
|
||||
- **Tasks**:
|
||||
- Implement middleware system
|
||||
- Support both global and route-specific middleware
|
||||
- Implement common middleware (CORS, authentication, etc.)
|
||||
- **Considerations**:
|
||||
- Ensure efficient middleware execution
|
||||
- Implement prioritization for middleware order
|
||||
|
||||
## Phase 4: Security and Authentication
|
||||
|
||||
### 4.1 Hashing
|
||||
**Description**: Provides secure Bcrypt and Argon2 hashing for storing user passwords.
|
||||
|
||||
- **Dependencies**: Support, Contracts
|
||||
- **Dart packages**: crypto
|
||||
- **Angel3 equivalent**: Partial (in angel3_auth)
|
||||
- **Tasks**:
|
||||
- Implement secure password hashing
|
||||
- Support multiple hashing algorithms
|
||||
- Implement password verification and rehashing
|
||||
- **Considerations**:
|
||||
- Stay updated with latest cryptographic standards
|
||||
- Implement password strength validation
|
||||
|
||||
### 4.2 Encryption
|
||||
**Description**: Provides simple encryption and decryption of arbitrary data using OpenSSL.
|
||||
|
||||
- **Dependencies**: Support, Contracts
|
||||
- **Dart packages**: encrypt
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement data encryption and decryption
|
||||
- Support symmetric and asymmetric encryption
|
||||
- Implement secure key management
|
||||
- **Considerations**:
|
||||
- Ensure compliance with encryption standards
|
||||
- Implement key rotation and management features
|
||||
|
||||
### 4.3 Auth
|
||||
**Description**: Provides authentication services for the framework, including various guards and providers.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Cookie, Events, Http, Session
|
||||
- **Dart packages**: firebase_auth, google_sign_in, oauth2
|
||||
- **Angel3 equivalent**: angel3_auth
|
||||
- **Tasks**:
|
||||
- Implement authentication system
|
||||
- Support multiple authentication guards and providers
|
||||
- Implement password reset and email verification
|
||||
- **Considerations**:
|
||||
- Ensure compatibility with existing Angel3 auth
|
||||
- Implement support for JWT and OAuth2
|
||||
|
||||
### 4.4 Passport
|
||||
**Description**: Provides a full OAuth2 server implementation, supporting personal access tokens and API authentication.
|
||||
|
||||
- **Dependencies**: Support, Database, Encryption, Http
|
||||
- **Dart packages**: oauth2
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement OAuth2 server
|
||||
- Support personal access tokens
|
||||
- Implement scope-based permissions
|
||||
- **Considerations**:
|
||||
- Ensure compliance with OAuth2 standards
|
||||
- Implement token revocation and refresh mechanisms
|
||||
|
||||
### 4.5 Sanctum
|
||||
**Description**: Provides a lightweight authentication system for SPAs, mobile applications, and simple token-based APIs.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Database
|
||||
- **Dart packages**: Custom implementation
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement lightweight authentication system for SPAs and mobile apps
|
||||
- Support token-based authentication
|
||||
- Implement CSRF protection for cookies
|
||||
- **Considerations**:
|
||||
- Balance between security and simplicity
|
||||
- Implement rate limiting for token generation
|
||||
|
||||
## Phase 5: Views and Console
|
||||
|
||||
### 5.1 View
|
||||
**Description**: Provides a simple and elegant template engine, supporting template inheritance and automatic data sharing.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Filesystem, Events
|
||||
- **Dart packages**: mustache, jinja
|
||||
- **Angel3 equivalent**: angel3_jael
|
||||
- **Tasks**:
|
||||
- Implement template rendering system
|
||||
- Support multiple template engines
|
||||
- Implement view composers and shared data
|
||||
- **Considerations**:
|
||||
- Maintain compatibility with Jael templating
|
||||
- Implement template caching for performance
|
||||
|
||||
### 5.2 Console
|
||||
**Description**: Provides a robust console application framework, including powerful command scheduling capabilities.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Events
|
||||
- **Dart packages**: args, cli_util
|
||||
- **Angel3 equivalent**: angel3_cli
|
||||
- **Tasks**:
|
||||
- Implement command-line interface
|
||||
- Support command arguments and options
|
||||
- Implement progress bars and table output
|
||||
- **Considerations**:
|
||||
- Ensure compatibility with existing Angel3 CLI
|
||||
- Implement plugin system for custom commands
|
||||
|
||||
### 5.3 Blade
|
||||
**Description**: Provides a powerful templating engine with template inheritance and components.
|
||||
|
||||
- **Dependencies**: Support, Container, Contracts, Filesystem, View
|
||||
- **Dart packages**: mustache, jinja
|
||||
- **Angel3 equivalent**: angel3_jael
|
||||
- **Tasks**:
|
||||
- Implement Blade-like templating engine
|
||||
- Support template inheritance and components
|
||||
- Implement template compilation for performance
|
||||
- **Considerations**:
|
||||
- Balance between Blade syntax and Dart language features
|
||||
- Implement efficient template caching mechanism
|
||||
|
||||
## Phase 6: Advanced Features
|
||||
|
||||
### 6.1 Queue
|
||||
**Description**: Provides a unified API for various queue backends, allowing you to defer the processing of time-consuming tasks.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Database, Events, Encryption
|
||||
- **Dart packages**: async, worker_manager
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement job queuing system
|
||||
- Support multiple queue drivers
|
||||
- Implement job retries and error handling
|
||||
- **Considerations**:
|
||||
- Ensure scalability for high-volume queues
|
||||
- Implement delayed and scheduled jobs
|
||||
|
||||
### 6.2 Broadcasting
|
||||
**Description**: Provides a simple way to implement real-time, websocket-based events in your application.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Events, Queue
|
||||
- **Dart packages**: web_socket_channel, socket_io_client
|
||||
- **Angel3 equivalent**: angel3_websocket
|
||||
- **Tasks**:
|
||||
- Implement real-time event broadcasting
|
||||
- Support WebSockets and server-sent events
|
||||
- Implement channel authentication
|
||||
- **Considerations**:
|
||||
- Ensure compatibility with existing Angel3 WebSocket support
|
||||
- Implement scaling for multiple server instances
|
||||
|
||||
### 6.3 Mail
|
||||
**Description**: Provides a clean, simple API over popular email sending libraries like SwiftMailer.
|
||||
|
||||
- **Dependencies**: Support, Container, Contracts, Events, View
|
||||
- **Dart packages**: mailer
|
||||
- **Angel3 equivalent**: angel3_mail
|
||||
- **Tasks**:
|
||||
- Implement mailing system
|
||||
- Support multiple mail drivers
|
||||
- Implement email queuing and templating
|
||||
- **Considerations**:
|
||||
- Implement support for attachments and inline attachments
|
||||
- Ensure proper email header management
|
||||
|
||||
### 6.4 Notifications
|
||||
**Description**: Provides support for sending notifications across a variety of delivery channels, including mail, SMS, and Slack.
|
||||
|
||||
- **Dependencies**: Support, Container, Contracts, Mail, Queue
|
||||
- **Dart packages**: flutter_local_notifications, firebase_messaging
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement notification system
|
||||
- Support multiple notification channels
|
||||
- Implement notification queuing and batching
|
||||
- **Considerations**:
|
||||
- Design for easy addition of new notification channels
|
||||
- Implement rate limiting for notifications
|
||||
|
||||
### 6.5 Redis
|
||||
**Description**: Provides an expressive interface for interacting with Redis, supporting caching, queues, and real-time events.
|
||||
|
||||
- **Dependencies**: Support, Contracts
|
||||
- **Dart packages**: redis
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement Redis client
|
||||
- Support pub/sub, caching, and queuing with Redis
|
||||
- Implement Redis-based session driver
|
||||
- **Considerations**:
|
||||
- Implement connection pooling for performance
|
||||
- Support Redis Cluster for scalability
|
||||
|
||||
### 6.6 Bus
|
||||
**Description**: Provides a simple, unified API over a variety of queue systems, allowing for easy swapping of backing technologies.
|
||||
|
||||
- **Dependencies**: Support, Container, Pipeline
|
||||
- **Dart packages**: async
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement command and event bus
|
||||
- Support synchronous and asynchronous dispatching
|
||||
- Implement middleware for commands
|
||||
- **Considerations**:
|
||||
- Design for easy extensibility with custom handlers
|
||||
- Implement logging and monitoring capabilities
|
||||
|
||||
### 6.7 Scout
|
||||
**Description**: Provides a driver based solution for adding full-text search to your Eloquent models.
|
||||
|
||||
- **Dependencies**: Support, Database, Contracts
|
||||
- **Dart packages**: algolia
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement full-text search capabilities
|
||||
- Support multiple search drivers (Algolia, Elasticsearch)
|
||||
- Implement searchable model trait
|
||||
- **Considerations**:
|
||||
- Design for easy addition of new search drivers
|
||||
- Implement efficient indexing strategies
|
||||
|
||||
## Phase 7: Testing and Development Tools
|
||||
|
||||
### 7.1 Testing
|
||||
**Description**: Provides a set of helpful tools and assertions to make application testing easier and more expressive.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Http
|
||||
- **Dart packages**: test, mockito
|
||||
- **Angel3 equivalent**: angel3_test
|
||||
- **Tasks**:
|
||||
- Implement testing utilities
|
||||
- Support HTTP testing, database testing, and mocking
|
||||
- Implement test factories and database transactions for tests
|
||||
- **Considerations**:
|
||||
- Ensure compatibility with existing Angel3 test utilities
|
||||
- Implement performance profiling tools
|
||||
|
||||
### 7.2 Tinker
|
||||
**Description**: Provides a powerful REPL for interacting with your application.
|
||||
|
||||
- **Dependencies**: Support, Console
|
||||
- **Dart packages**: dart:io
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement REPL for application interaction
|
||||
- Support code execution in application context
|
||||
- Implement auto-completion and history
|
||||
- **Considerations**:
|
||||
- Ensure security when executing arbitrary code
|
||||
- Implement helpful debugging information display
|
||||
|
||||
### 7.3 Telescope
|
||||
**Description**: Provides insight into the requests coming into your application, exceptions, log entries, database queries, queued jobs, mail, notifications, cache operations, scheduled tasks, variable dumps, and more.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Database, Encryption
|
||||
- **Dart packages**: logging, sentry
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement debugging and profiling tool
|
||||
- Support request monitoring and error tracking
|
||||
- Implement performance insights
|
||||
- **Considerations**:
|
||||
- Design for minimal performance impact in production
|
||||
- Implement data pruning to manage storage
|
||||
|
||||
### 7.4 Dusk
|
||||
**Description**: Provides an expressive, easy-to-use browser automation and testing API.
|
||||
|
||||
- **Dependencies**: Support, Contracts, Console
|
||||
- **Dart packages**: webdriver
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement browser automation testing framework
|
||||
- Support multiple browsers
|
||||
- Implement page object pattern
|
||||
- **Considerations**:
|
||||
- Ensure cross-browser compatibility
|
||||
- Implement parallel test execution for performance
|
||||
|
||||
## Phase 8: Framework Integration
|
||||
|
||||
### 8.1 Foundation
|
||||
**Description**: Ties together all Laravel components, including the IoC container definition, the console kernel definition, and more.
|
||||
|
||||
- **Dependencies**: Support, Container, Contracts, Http, Config, Events, Log, Routing
|
||||
- **Dart packages**: Custom implementation
|
||||
- **Angel3 equivalent**: angel3_framework
|
||||
- **Tasks**:
|
||||
- Implement core application class
|
||||
- Tie together all components
|
||||
- Implement service provider system and application lifecycle
|
||||
- **Considerations**:
|
||||
- Ensure backward compatibility with Angel3 applications
|
||||
- Implement performance optimizations
|
||||
|
||||
### 8.2 Service Providers
|
||||
**Description**: Provides a central place of bootstrapping for all of the framework's various components.
|
||||
|
||||
- **Dependencies**: Support, Container
|
||||
- **Dart packages**: get_it, injectable
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement service provider system
|
||||
- Support deferred providers
|
||||
- Implement provider discovery and automatic registration
|
||||
- **Considerations**:
|
||||
- Ensure lazy loading of services for performance
|
||||
- Implement dependency injection container
|
||||
|
||||
### 8.3 Facades
|
||||
**Description**: Provides a static interface to classes that are available in the application's IoC container.
|
||||
|
||||
- **Dependencies**: Support, Container
|
||||
- **Dart packages**: Custom implementation
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement facade-like static accessors
|
||||
- Consider Dart's limitations and best practices
|
||||
- Implement real-time facade resolution
|
||||
- **Considerations**:
|
||||
- Balance between Laravel-like syntax and Dart idioms
|
||||
- Ensure type safety and IDE support
|
||||
|
||||
### 8.4 Macroable
|
||||
**Description**: Allows you to add methods to classes at runtime.
|
||||
|
||||
- **Dependencies**: Support
|
||||
- **Dart packages**: Custom implementation
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement trait for adding macro capabilities to classes
|
||||
- Support dynamic method addition
|
||||
- Implement scoped macros
|
||||
- **Considerations**:
|
||||
- Consider Dart's static typing constraints
|
||||
- Implement efficient method resolution
|
||||
|
||||
### 8.5 Pipeline
|
||||
**Description**: Provides a way to pass an object through a series of stages or "pipes", each performing an action on the object.
|
||||
|
||||
- **Dependencies**: Support, Contracts
|
||||
- **Dart packages**: Custom implementation
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement pipeline pattern
|
||||
- Support both synchronous and asynchronous pipes
|
||||
- Implement pipeline testing utilities
|
||||
- **Considerations**:
|
||||
- Optimize for performance with long pipelines
|
||||
- Implement error handling and pipeline interruption
|
||||
|
||||
### 8.6 Conditionable
|
||||
**Description**: Allows for the fluent definition of conditional logic in objects.
|
||||
|
||||
- **Dependencies**: Support
|
||||
- **Dart packages**: Custom implementation
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement trait for adding conditional execution to classes
|
||||
- Support fluent conditionals
|
||||
- Implement nested conditions
|
||||
- **Considerations**:
|
||||
- Ensure readability of complex conditional chains
|
||||
- Optimize for performance with multiple conditions
|
||||
|
||||
### 8.7 Stringable
|
||||
**Description**: Provides a fluent interface for string manipulation.
|
||||
|
||||
- **Dependencies**: Support, Macroable
|
||||
- **Dart packages**: dart:core, characters
|
||||
- **Angel3 equivalent**: None
|
||||
- **Tasks**:
|
||||
- Implement fluent string manipulation
|
||||
- Support multibyte-safe string operations
|
||||
- Implement string transformation methods
|
||||
- **Considerations**:
|
||||
- Ensure proper handling of different character encodings
|
||||
- Optimize for performance with large strings
|
||||
|
||||
## Phase 9: Final Integration and Optimization
|
||||
|
||||
### 9.1 Performance Optimization
|
||||
- Conduct thorough performance testing
|
||||
- Optimize critical paths and frequently used components
|
||||
- Implement caching strategies across the framework
|
||||
|
||||
### 9.2 Documentation
|
||||
- Write comprehensive API documentation
|
||||
- Create migration guides for Angel3 users
|
||||
- Develop tutorials and example applications
|
||||
|
||||
### 9.3 Community Engagement
|
||||
- Establish contribution guidelines
|
||||
- Set up forums or discussion platforms
|
||||
- Plan for long-term maintenance and support
|
||||
|
||||
This comprehensive roadmap provides a detailed guide for reimplementing Laravel's Illuminate packages in Dart, building on Angel3's foundation. It covers all major components, including advanced features, and provides context and considerations for each package. By following this roadmap, the project will successfully replicate Laravel's functionality in Dart, while also taking advantage of Dart's unique features and best practices.
|
Loading…
Reference in a new issue