Application Structure
Relevant source files
The following files were used as context for generating this wiki page:The Becathlon project is a Django-powered e-commerce platform designed with a modular architecture. The structure separates concerns into distinct Django "apps," each responsible for a specific domain of functionality, such as user authentication, product catalog, or order management. This approach promotes a clean, scalable, and maintainable codebase, suitable for learning Django patterns and for future expansion.
The project follows standard Django conventions, with a main project directory (becathlon/) for global configuration and a dedicated apps/ directory to house the individual application modules. The frontend is built with HTML5, CSS3, and vanilla JavaScript, with static files organized within each app and collected for production deployment.
Sources: README.md:10-14, 131-133, IMPLEMENTATION.md:92-111, becathlon/settings.py:16-17, 68-79
High-Level Directory Structure
The project's root contains the becathlon configuration directory, the apps directory for all modules, and other project-level files. The apps directory is explicitly added to the Python path to allow for cleaner imports.
This diagram shows the main directories at the root of the project.
Sources: IMPLEMENTATION.md:92-111, becathlon/settings.py:16-17
Django Application Modules
The core logic is divided into several Django applications, each residing in the apps/ directory. This modular design isolates features, making them easier to develop, test, and maintain.
The following diagram illustrates the key applications and their primary purpose.
This diagram shows the logical grouping of the Django apps and their high-level interactions.
Sources: README.md:82-97, becathlon/settings.py:68-79
Module Breakdown
The table below details each application module, its purpose, and its key components.
| App Name | Purpose | Key Components |
|---|---|---|
main | Homepage, navigation, footer, and other static pages. | home.html, base templates, AJAX endpoints for product loading. |
authentication | User login, registration, and logout. | login.html, signup.html, custom SignUpForm. |
catalog | Product listings, categories, and product details. | Product model, product grid, quick view modal, filtering logic. |
cart | Shopping cart management. | Session-based and persistent cart logic, cart_view.html. |
order | Order history and mock refunds. | Order and OrderItem models, order_list.html. |
profiles | User profiles, preferences, and account type management. | Profile model, profile_detail.html, newsletter toggle. |
stores | Store locator with mock locations. | Store model, map integration. |
recommendation | Product recommendation system. | Logic for personalized recommendations. |
search | Search functionality with filters. | Search views and templates. |
Sources: README.md:82-97, IMPLEMENTATION.md:5-29
Configuration (settings.py)
The main configuration for the Django project is located in becathlon/settings.py. It defines installed apps, middleware, database connections, and static file handling.
Sources: becathlon/settings.py
Installed Applications
The INSTALLED_APPS setting registers all the application modules with the Django project. The project uses both Django's built-in apps and its own custom apps from the apps/ directory.
# becathlon/settings.py:66-79
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'apps.main.apps.MainConfig',
'apps.authentication.apps.AuthenticationConfig',
'apps.catalog.apps.CatalogConfig',
'apps.cart.apps.CartConfig',
'apps.profiles.apps.ProfilesConfig',
'apps.stores.apps.StoresConfig',
'apps.recommendation.apps.RecommendationConfig',
'apps.order.apps.OrderConfig',
]
Sources: becathlon/settings.py:66-79
Middleware
The project uses a standard set of Django middleware, with the addition of whitenoise.middleware.WhiteNoiseMiddleware for serving static files in production.
This diagram shows the request/response flow through the configured middleware.
Sources: becathlon/settings.py:81-90
Database Configuration
The application is configured to use two different database backends depending on the environment:
- Production: PostgreSQL, using environment variables for credentials (
DB_NAME,DB_USER, etc.). - Local Development: SQLite, as a fallback when PostgreSQL credentials are not provided.
This dual configuration allows for easy local setup while using a more robust database for deployment.
Sources: becathlon/settings.py:102-136
Static and Media Files
Static files (CSS, JS, images) are managed using Django's staticfiles app.
STATIC_URL:/static/STATIC_ROOT:BASE_DIR / 'staticfiles'(where files are collected for production)STATICFILES_DIRS: Astatic/directory at the project root can be used for global static files.- Storage:
whitenoise.storage.CompressedStaticFilesStorageis used in production to serve compressed static files efficiently.
Each app also contains its own static/ directory (e.g., apps/catalog/static/), which is a standard Django practice for organizing app-specific assets.
Sources: becathlon/settings.py:175-202, apps/catalog/static/catalog/js/catalog.js, apps/profiles/static/profiles/css/profiles.css
Frontend Structure
The frontend is structured using Django's templating system, with app-specific CSS and JavaScript files.
Template Inheritance
The project uses a base template system to maintain a consistent layout. Individual apps often have their own base template that extends a global one, and then app-specific pages extend the app's base.
For example, apps/profiles/profile_detail.html extends catalog/base_catalog.html, which likely provides the main site navigation and footer. This creates a hierarchical and reusable template structure.
This diagram illustrates the template inheritance hierarchy.
Sources: apps/profiles/templates/profiles/profile_detail.html:1, apps/stores/templates/stores/base_stores.html:1, apps/profiles/templates/profiles/base_profiles.html:1
User Roles
The application defines three distinct user roles, each with a different set of permissions and access to modules. This separation is fundamental to the application's structure and security model.
| Role | Description | Relevant Modules |
|---|---|---|
| Guest / Visitor | Unregistered users browsing the site. | main, catalog, search, cart (session-based) |
| Client / Customer | Registered shoppers with an account. | authentication, profiles, cart (persistent), checkout, orders |
| Administrator | Full control over the platform via Django admin. | All modules, primarily through admin.py files. |
Sources: README.md:102-120
Conclusion
The Becathlon application is built on a solid, modular Django architecture. By dividing functionality into discrete apps, the project remains organized and scalable. The clear separation between backend logic (apps, models, views), frontend presentation (templates, static files), and configuration (settings.py) follows Django best practices, making it an excellent reference for full-stack web development. The structure supports different user roles and is designed for both local development and production deployment.
Sources: README.md:131-133, IMPLEMENTATION.md:92-95