Hi,
I read the books: Django for Beginners, Build a Website with Django and Mastering Django and went through the turtorial on the Django Project website.
I am struggling with the arhcitecture of the web application. I need a custom admin site for the superuser and staff users in which I manage the models, I need a backend in which non-staff/non-superuser users manage their content, and I need a frontend.
The models will be the same for all three, the views and templates will be different.
I thought of a structure like this:
I’d like to build all three applications in Django and later consider another frontend.
Any comment on this idea will be very much appreciated.
Kind regards,
Johanna
hey, wrap you folder structure in triple back-ticks, so it becomes more readable 
It doesn’t need to be that complicated.
I’m not sure I understand what you mean in this context of “frontend” vs “backend” - it sounds to me like they’re just different pages within the same “system”.
I’m a member of the “One app unless proven otherwise” camp. I don’t know how many pages you’re looking at, or whether you’re planning on using one of these apps in multiple applications, but I’d start building this as one app using the same structure as the tutorials you’ve worked through. One project, one app.
(There are a couple other threads here in the forum talking about one vs multiple apps. See Why do we need apps? and Project organization- when is something a separate app?)
here’s an idea:
. keep all your models at the top of your folder structure
. have a “site” or “portal” folder at you top level: under this, you can have “admin” (the “backend UI”) and “web” (the "frontend-customer-facing-UI), or again “admindjango” for the native admin tool (which is great, btw )
. organise your settings files so there is one such file for each site/portal (all potentially inheriting from a “common” settings file).
. each “site” folder then declares its own “local urls.py, views,py, forms.py”, etc.
. your virtualenv can sit anywhere. usually NOT within the source tree though (or add it to your .gitignore file).
. think about env variables (uwsgi, etc). that bubble up from .ini files to your python code (“devops” style though I don’t personnaly particularly like that word).
something like:
|_ model1
|_ model2
|_ model3
|_ model4
|_ model5
|_ model6
|_ sites
| |_ web
| | |_ urls.py
| | |_ views.py
| |_ admin
| | |_ urls.py
| | |_ views.py
| | _ backend
| |_ urls.py
| |_ home
| |_ urls.py
| |_ views.py
|_ settings
|_ common.py
|_ web.py
|_ admin.py
|_ backend.py
Important: DJANGO_SETTINGS_MODULE. Look it up.
Hi Ken,
Thanks for your reply and the references to the other threads.
I developed a web application in another framework. I started with one application. An application in that framework has amongst others a models/db.py model, a controllers/default.py controller and a views directory containing the templates.
After a while I started splitting db.py into separate model files which I named core.py calendar.py advert.py for example. I did the same for the default.py controller and the views (templates)
So I had a calender.py model file a calendar.py controller file and a calendar directory with all the template related code.
Migrations were a hassle, so I decided to move all model files into a separate application. (In Django I like manage.py makemigrations appname)
I still had the backend (authorisation and authentication required using decorators) and frontend in one application. I finally decided to split this one application into two applications a cms like application and a web site application.
I wanted to rebuild the web application in Django, so I freed my mind from the other framework and made a fresh start learning Django.
I hope I provided you with sufficient information to better understand my question.
Kind regards,
Johanna
Hi Plopidou,
Thanks for you reply.
Your idea comes close to what I had in mind. I’ll look up the things you mention
in the Django documentation.
Kind regards,
Johanna
There may be a little bit of a terminology issue here confusing the situation.
It almost sounds to me like what you’re referring to as an “application” is closer to what Django would call a “project”. A Django application is part of a project. The key difference here is that all the applications within a project run in the same runtime environment. (One settings file, one instance of uwsgi / gunicorn, etc.) Each project is generally run in independent instances.
To give you some idea - I’ve got a project that is up to about 140 models, more than 300 views, and about 8 different subcomponents. But there are only 5 apps, and one of them is a reusable “menu” app.
I’ve got two separate projects that work with the same data as the main project, but run in different environments and independent of that main project. (They’re both very small. One is just an “admin dashboard” displaying some information about the system for the sys admins.)
