mirror of
https://github.com/pacnpal/thrillwiki_laravel.git
synced 2025-12-20 05:31:10 -05:00
bd08111971
- Added Ride CRUD system documentation detailing implementation summary, generated components, and performance metrics. - Created Ride CRUD system prompt for future development with core requirements and implementation strategy. - Established relationships between rides and parks, ensuring Django parity and optimized performance. - Implemented waiting for user command execution documentation for Park CRUD generation. - Developed Livewire components for RideForm and RideList with basic structure. - Created feature tests for Park and Ride components, ensuring proper rendering and functionality. - Added comprehensive tests for ParkController, ReviewImage, and ReviewReport models, validating CRUD operations and relationships.
248 lines
11 KiB
Markdown
248 lines
11 KiB
Markdown
# Ride CRUD System Implementation Prompt
|
|
|
|
**Date**: June 22, 2025
|
|
**Priority**: HIGH - Next Major Implementation
|
|
**Status**: 🔄 **READY FOR IMPLEMENTATION**
|
|
|
|
## 🎠 **RIDE CRUD SYSTEM DEVELOPMENT PROMPT**
|
|
|
|
### **Objective**
|
|
Implement a complete Ride CRUD system leveraging the proven patterns established from the successful Park CRUD system implementation. Apply 99% time reduction using ThrillWiki custom generators.
|
|
|
|
### **Implementation Strategy**
|
|
**Leverage Established Patterns**: Use the successful Park system patterns for rapid development
|
|
- **Pattern Reuse**: Copy proven Park component architecture
|
|
- **ThrillWiki Generators**: Utilize custom artisan commands for acceleration
|
|
- **Django Parity**: Maintain 100% feature equivalence with Django ride system
|
|
- **Mobile-First**: Apply same responsive design standards
|
|
|
|
### **Primary Generator Command**
|
|
```bash
|
|
php artisan make:thrillwiki-crud Ride --api --with-tests
|
|
```
|
|
|
|
### **Core Requirements**
|
|
|
|
#### **1. Ride Entity Features (Based on Django Parity)**
|
|
- **Basic Information**: Name, description, ride type, status
|
|
- **Technical Specifications**: Height requirements, duration, capacity
|
|
- **Relationships**: Park (belongsTo), manufacturer, designer, area
|
|
- **Statistics**: Rider count, popularity metrics, safety records
|
|
- **Operational Data**: Opening/closing dates, seasonal availability
|
|
|
|
#### **2. Advanced Features (Beyond Basic CRUD)**
|
|
- **Ride Type Filtering**: Roller coaster, flat ride, water ride, dark ride categories
|
|
- **Technical Specifications**: Speed, height, inversions, length
|
|
- **Safety Information**: Height restrictions, health warnings, accessibility
|
|
- **Real-time Status**: Operating, closed, maintenance, weather-dependent
|
|
- **Capacity Management**: Throughput, queue times, ride capacity
|
|
|
|
#### **3. Livewire Components to Generate**
|
|
|
|
**RideListComponent** (Following Park Pattern):
|
|
- **Advanced Search**: Name, ride type, park, manufacturer search
|
|
- **Multi-criteria Filtering**: Status, type, park, height requirements
|
|
- **Comprehensive Sorting**: Name, opening date, popularity, thrill level
|
|
- **View Modes**: Grid view (ride cards) and list view (compact table)
|
|
- **Performance**: Pagination, eager loading, mobile optimization
|
|
|
|
**RideFormComponent** (Following Park Pattern):
|
|
- **Create/Edit Modes**: New ride creation and existing ride modification
|
|
- **Relationship Management**: Park selection, manufacturer/designer dropdowns
|
|
- **Technical Fields**: Height requirements, duration, capacity inputs
|
|
- **Validation**: Comprehensive validation rules with real-time feedback
|
|
- **File Uploads**: Support for ride photos and technical documents
|
|
|
|
#### **4. Ride-Specific Extensions**
|
|
|
|
**Additional Features Beyond Park Pattern**:
|
|
- **Coaster Statistics**: Track inversions, speed, height for roller coasters
|
|
- **Safety Validation**: Ensure height requirements are within reasonable ranges
|
|
- **Manufacturer Integration**: Enhanced manufacturer relationship with ride types
|
|
- **Park Area Integration**: Optional park area assignment for location within park
|
|
- **Queue Time Integration**: Foundation for future wait time features
|
|
|
|
### **Technical Implementation Details**
|
|
|
|
#### **Smart Trait Integration (Automatic)**
|
|
- **HasSlugHistory**: Ride slug management and history tracking
|
|
- **HasStatistics**: Rider counts and popularity metrics
|
|
- **SoftDeletes**: Safe deletion with recovery capability
|
|
- **HasCaching**: Performance optimization for frequently accessed rides
|
|
|
|
#### **Relationship Configuration (Pre-configured)**
|
|
- **park**: belongsTo(Park) - Required parent relationship
|
|
- **area**: belongsTo(ParkArea) - Optional location within park
|
|
- **manufacturer**: belongsTo(Operator, 'manufacturer_id') - Ride manufacturer
|
|
- **designer**: belongsTo(Operator, 'designer_id') - Ride designer
|
|
- **photos**: morphMany(Photo) - Ride image gallery
|
|
- **reviews**: morphMany(Review) - User reviews and ratings
|
|
|
|
#### **Database Schema Requirements**
|
|
```sql
|
|
-- Key fields to be generated:
|
|
name (string, required, unique within park)
|
|
slug (string, indexed)
|
|
description (text, nullable)
|
|
ride_type (enum: coaster, flat, water, dark, transport)
|
|
status (enum: operating, closed, maintenance, seasonal)
|
|
park_id (foreign key, required)
|
|
area_id (foreign key, nullable)
|
|
manufacturer_id (foreign key, nullable)
|
|
designer_id (foreign key, nullable)
|
|
opening_date (date, nullable)
|
|
closing_date (date, nullable)
|
|
height_requirement_min (integer, nullable, cm)
|
|
height_requirement_max (integer, nullable, cm)
|
|
duration_minutes (decimal, nullable)
|
|
capacity_per_hour (integer, nullable)
|
|
max_speed_kmh (decimal, nullable)
|
|
max_height_meters (decimal, nullable)
|
|
inversions_count (integer, nullable, default 0)
|
|
length_meters (decimal, nullable)
|
|
ride_count (bigint, default 0)
|
|
popularity_score (decimal, default 0.0)
|
|
```
|
|
|
|
### **Mobile-First Requirements**
|
|
|
|
#### **Performance Targets**
|
|
- **3G Network Support**: <3 second load times on mobile networks
|
|
- **Touch Targets**: Minimum 44px for all interactive elements
|
|
- **Responsive Design**: Mobile-first with breakpoints (320px, 768px, 1024px, 1280px)
|
|
- **Progressive Enhancement**: Works without JavaScript, enhanced with Livewire
|
|
|
|
#### **User Experience Standards**
|
|
- **Search Optimization**: Debounced search (300ms) with loading indicators
|
|
- **Filter Persistence**: Query string persistence for bookmarkable filter states
|
|
- **Touch Gestures**: Swipe navigation between ride details
|
|
- **Loading States**: Skeleton screens during data fetching
|
|
|
|
### **Django Parity Requirements**
|
|
|
|
#### **Feature Equivalence**
|
|
- **Search Functionality**: Text search across name, description, park
|
|
- **Filtering Options**: Status, type, park, height requirements
|
|
- **Sorting Capabilities**: Name, date, popularity, technical specifications
|
|
- **CRUD Operations**: Create, read, update, delete with proper validation
|
|
- **Relationship Management**: Seamless park and manufacturer integration
|
|
|
|
#### **Data Validation (Django-equivalent)**
|
|
- **Name Uniqueness**: Unique within park scope
|
|
- **Height Requirements**: Logical validation (min < max, reasonable ranges)
|
|
- **Technical Specifications**: Non-negative values for speed, height, capacity
|
|
- **Date Validation**: Opening date before closing date, reasonable date ranges
|
|
- **Relationship Integrity**: Valid park, manufacturer, designer references
|
|
|
|
### **Testing Requirements**
|
|
|
|
#### **Automated Test Coverage**
|
|
- **Component Tests**: RideListComponent and RideFormComponent functionality
|
|
- **Feature Tests**: CRUD operations, search, filtering, sorting
|
|
- **Validation Tests**: Form validation rules and error handling
|
|
- **Relationship Tests**: Park, manufacturer, designer associations
|
|
- **Performance Tests**: Query optimization and mobile performance
|
|
|
|
#### **Test Scenarios**
|
|
- **Create Ride**: New ride creation with full validation
|
|
- **Edit Ride**: Modification of existing rides with relationship updates
|
|
- **Search Functionality**: Text search across multiple fields
|
|
- **Filter Combinations**: Multiple filter criteria simultaneously
|
|
- **Sort Operations**: All sort fields with ascending/descending
|
|
- **Mobile Interaction**: Touch targets and responsive behavior
|
|
|
|
### **Success Criteria**
|
|
|
|
#### **Completion Metrics**
|
|
- ✅ **RideListComponent**: Advanced search, filtering, sorting, pagination
|
|
- ✅ **RideFormComponent**: Create/edit forms with comprehensive validation
|
|
- ✅ **Component Views**: Mobile-first responsive templates
|
|
- ✅ **Component Tests**: Full test coverage for both components
|
|
- ✅ **Django Parity**: 100% feature equivalence achieved
|
|
- ✅ **Mobile Optimization**: Touch-friendly, 3G network optimized
|
|
- ✅ **Documentation**: Complete Memory Bank documentation
|
|
|
|
#### **Performance Benchmarks**
|
|
- **Generation Speed**: <5 seconds total generation time (99% faster than manual)
|
|
- **Load Performance**: <3 seconds on 3G networks
|
|
- **Query Efficiency**: <50ms database queries with eager loading
|
|
- **Mobile Usability**: 44px touch targets, thumb-friendly navigation
|
|
|
|
### **Implementation Process**
|
|
|
|
#### **Step 1: Generate Foundation**
|
|
```bash
|
|
php artisan make:thrillwiki-crud Ride --api --with-tests
|
|
```
|
|
|
|
#### **Step 2: Verify Generation**
|
|
- Confirm all files are created successfully
|
|
- Check component classes exist and are properly structured
|
|
- Verify view templates are generated with ThrillWiki patterns
|
|
- Ensure test files are created with comprehensive coverage
|
|
|
|
#### **Step 3: Customize Ride-Specific Features**
|
|
- Add ride type filtering logic
|
|
- Implement technical specification fields
|
|
- Enhance manufacturer/designer relationships
|
|
- Add coaster-specific statistics tracking
|
|
|
|
#### **Step 4: Test Implementation**
|
|
- Run automated test suite
|
|
- Verify mobile responsiveness
|
|
- Test search and filtering functionality
|
|
- Validate Django parity compliance
|
|
|
|
#### **Step 5: Document Results**
|
|
- Update Memory Bank with implementation details
|
|
- Document any customizations or deviations
|
|
- Record performance metrics and benchmarks
|
|
- Prepare for next entity implementation
|
|
|
|
### **Expected Deliverables**
|
|
|
|
#### **Generated Files**
|
|
- **RideListComponent** (~130-150 lines)
|
|
- **RideFormComponent** (~100-120 lines)
|
|
- **Component Views** (~300-350 total lines)
|
|
- **Component Tests** (~70-90 total lines)
|
|
- **Ride Controller** (Full CRUD with API endpoints)
|
|
- **Ride Views** (index, show, create, edit)
|
|
- **RideRequest** (Form validation)
|
|
- **Database Migration** (If needed)
|
|
|
|
#### **Documentation Updates**
|
|
- **Memory Bank Documentation**: Complete implementation record
|
|
- **Pattern Documentation**: Ride-specific patterns and extensions
|
|
- **Test Coverage Report**: Comprehensive test verification
|
|
- **Performance Metrics**: Mobile optimization and load time results
|
|
|
|
### **Risk Mitigation**
|
|
|
|
#### **Potential Challenges**
|
|
- **Complex Relationships**: Ride-park-manufacturer relationships
|
|
- **Technical Field Validation**: Speed, height, capacity validation rules
|
|
- **Mobile Performance**: Large dataset pagination and filtering
|
|
- **Django Parity**: Matching exact Django ride functionality
|
|
|
|
#### **Mitigation Strategies**
|
|
- **Leverage Park Patterns**: Use proven relationship management approaches
|
|
- **Incremental Testing**: Test each component as it's generated
|
|
- **Performance Monitoring**: Real-time performance validation
|
|
- **Reference Documentation**: Use Memory Bank Park patterns as reference
|
|
|
|
### **Next Steps After Completion**
|
|
|
|
#### **Immediate Follow-up**
|
|
1. **Test Suite Execution**: Verify all tests pass
|
|
2. **Performance Validation**: Confirm mobile optimization targets
|
|
3. **Django Parity Check**: Validate feature equivalence
|
|
4. **Documentation Update**: Complete Memory Bank updates
|
|
|
|
#### **Future Implementation Pipeline**
|
|
1. **🏢 Operator CRUD System**: Theme park operator management
|
|
2. **🔍 Global Search Components**: Cross-entity search with autocomplete
|
|
3. **📱 PWA Features**: Service worker and offline capabilities
|
|
4. **🌐 API Endpoints**: RESTful API for mobile app integration
|
|
|
|
**Status**: **READY FOR IMMEDIATE IMPLEMENTATION** ✅ |