mirror of
https://github.com/pacnpal/thrillwiki_django_no_react.git
synced 2025-12-20 06:51:08 -05:00
69c07d1381
- Introduced a new loading indicator GIF to improve user experience during asynchronous operations. - Added jQuery Ajax Queue plugin to manage queued Ajax requests, ensuring that new requests wait for previous ones to complete. - Implemented jQuery Autocomplete plugin for enhanced input fields, allowing users to receive suggestions as they type. - Included jQuery Bgiframe plugin to ensure proper rendering of elements in Internet Explorer 6.
54 lines
2.4 KiB
Plaintext
54 lines
2.4 KiB
Plaintext
# Project Startup Rules
|
|
|
|
## Development Server
|
|
IMPORTANT: Always follow these instructions exactly when starting the development server:
|
|
|
|
```bash
|
|
lsof -ti :8000 | xargs kill -9; find . -type d -name "__pycache__" -exec rm -r {} +; ./scripts/dev_server.sh
|
|
|
|
Note: These steps must be executed in this exact order as a single command to ensure consistent behavior. If server does not start correctly, do not attempt to modify the dev_server.sh script.
|
|
|
|
## Package Management
|
|
IMPORTANT: When a Python package is needed, only use UV to add it:
|
|
```bash
|
|
uv add <package>
|
|
```
|
|
Do not attempt to install packages using any other method.
|
|
|
|
## Django Management Commands
|
|
IMPORTANT: When running any Django manage.py commands (migrations, shell, etc.), always use UV:
|
|
```bash
|
|
uv run manage.py <command>
|
|
```
|
|
This applies to all management commands including but not limited to:
|
|
- Making migrations: `uv run manage.py makemigrations`
|
|
- Applying migrations: `uv run manage.py migrate`
|
|
- Creating superuser: `uv run manage.py createsuperuser` and possible echo commands before for the necessary data input.
|
|
- Starting shell: `uv run manage.py shell` and possible echo commands before for the necessary data input.
|
|
|
|
NEVER use `python manage.py` or `uv run python manage.py`. Always use `uv run manage.py` directly.
|
|
|
|
## Entity Relationship Rules
|
|
IMPORTANT: Follow these entity relationship patterns consistently:
|
|
|
|
# Park Relationships
|
|
- Parks MUST have an Operator (required relationship)
|
|
- Parks MAY have a PropertyOwner (optional, usually same as Operator)
|
|
- Parks CANNOT directly reference Company entities
|
|
|
|
# Ride Relationships
|
|
- Rides MUST belong to a Park (required relationship)
|
|
- Rides MAY have a Manufacturer (optional relationship)
|
|
- Rides MAY have a Designer (optional relationship)
|
|
- Rides CANNOT directly reference Company entities
|
|
|
|
# Entity Definitions
|
|
- Operators: Companies that operate theme parks (replaces Company.owner)
|
|
- PropertyOwners: Companies that own park property (new concept, optional)
|
|
- Manufacturers: Companies that manufacture rides (replaces Company for rides)
|
|
- Designers: Companies/individuals that design rides (existing concept)
|
|
|
|
# Relationship Constraints
|
|
- Operator and PropertyOwner are usually the same entity but CAN be different
|
|
- Manufacturers and Designers are distinct concepts and should not be conflated
|
|
- All entity relationships should use proper foreign keys with appropriate null/blank settings |