| 3 | | == Content |
| 4 | | To be defined. |
| | 3 | Description |
| | 4 | This phase presents a working prototype application that demonstrates |
| | 5 | how selected application scenarios from Phase P3 can be implemented |
| | 6 | using a real database and backend logic. |
| | 7 | |
| | 8 | Technology |
| | 9 | - Programming language: Python |
| | 10 | - Framework: Flask |
| | 11 | - Database: SQLite |
| | 12 | - Execution environment: Local development (Windows) |
| | 13 | |
| | 14 | Implemented Scenarios |
| | 15 | The prototype implements a representative subset of the application |
| | 16 | scenarios defined in Phase P3: |
| | 17 | |
| | 18 | 1. Listing weddings for a user |
| | 19 | 2. Viewing events for a selected wedding |
| | 20 | 3. Viewing guests for a wedding |
| | 21 | 4. Attendance overview for an event |
| | 22 | 5. RSVP overview for an event |
| | 23 | 6. Venue availability check with conflict detection |
| | 24 | |
| | 25 | Venue Availability Logic |
| | 26 | The application implements business logic to detect overlapping |
| | 27 | venue bookings for a selected date and time interval. |
| | 28 | |
| | 29 | If a conflict exists, the system returns: |
| | 30 | - available: false |
| | 31 | - list of conflicting bookings |
| | 32 | |
| | 33 | If no conflict exists, the system returns: |
| | 34 | - available: true |
| | 35 | |
| | 36 | Screenshots |
| | 37 | Below are screenshots demonstrating: |
| | 38 | - Wedding listing |
| | 39 | - Attendance overview |
| | 40 | - RSVP overview |
| | 41 | - Venue availability with conflict |
| | 42 | - Venue availability without conflict |
| | 43 | |
| | 44 | This prototype demonstrates the feasibility of implementing |
| | 45 | the database usage scenarios and validates the database design. |