21👍
You just need to make sure your structure makes sense to you.
There’s no requirement to create a new app for every feature that is bound to another part of the project’s logic.
Reusable apps are a whole different story, their code should be unaware of the implementation to some extent.
Take a look at Django’s structure for inspiration
A possible layout for your example:
project_root/
project/
__init__.py
settings.py
urls.py
templates/
app1/ # override stuff
static/
media/
app1/
__init__.py
admin/ # as a package
__init__.py
subjects.py
resources.py
# etc
models/ # as a package
subjects.py
resources.py
# etc
managers/
__init__.py
subjects.py
resources.py
# etc
services/
__init__.py
audio.py # upload handler etc
views/
__init__.py
subjects.py
urls/
__init__.py
subjects.py
templates/
app1/
subject_list.html # override at project level
static/
app1/
css/
subject.css # override at project level
app2/
__init__.py
models.py # holds a Member model or whatever you require
manage.py
16👍
I think the best way to delimit an app is roughly equivalent to the way you delimit a class on an Objected Oriented Programming Language. Instead of variables and methods, you think of models and views respectively:
models are the state of the object, views are used to see and interact with the state of the object.
My rule of thumb is, does creating an app help to encapsulate a specific set of models? If that is the case, then I try to create it.
- [Django]-ImproperlyConfigured: You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings
- [Django]-Pulling data to the template from an external database with django
- [Django]-Create a field whose value is a calculation of other fields' values