R
R
Roma Zvarich2015-10-13 19:59:13
Django
Roma Zvarich, 2015-10-13 19:59:13

How to properly organize a Django project (applications, templates, static files)?

Hello.
I consolidate my learning of Django by developing a project, which in the final version can be quite large.
But already at the initial steps, the question of organizing files in the project began to arise. I thought about how to make the project so that in case of a break it would be easy to remember what structure I adhered to and be able to understand it (or a developer who may be involved in the development of the project.
For example, at the moment I suspect that probably it is not very correct to make a separate application for each section of the site:
- an application that contains files common to all (base template, css-styles, logo, etc.).
- an application that serves only one section of the site (search for certain objects)
- an application for the functionality of adding these same objects to the site
- an application for displaying the main page
I decided to ask other developers for advice.
Maybe someone has already developed a convenient principle and will share it.
Question number 1: What is the best principle to create applications? So that one application covers the whole section (for example, there is a functionality for both filling the site and searching the site) or one application for filling, and the other for searching for objects?
Question #2: Where do you store common files (base template, css styles, logo)?
Question #3: How do you organize templates? (Basic, included and extended templates)
PS I found a good article on the organization of templates. True, this is within one application. I began to apply this principle myself. It seems more convenient.

Answer the question

In order to leave comments, you need to log in

3 answer(s)
A
Alexander Lebedev, 2015-10-15
@zymanch

I usually divide the subject areas of the project into separate applications. If some area is too extensive, then in the application folder I create separate applications for sub-areas. Each application has its own templates folder: this allows you not to get confused in the overgrown directory hierarchy with a large number of applications. In addition, I send all separate statics in the static directory of each application: sometimes I write JavaScript applications on Marionette for the interface to work - I always know where to look for the right bunch of scripts.
For example : we are writing a project for a dealer network for the distribution and sale of cars. It turns out like this:

./project_name/
./project_name/settings.py
./project_name/urls.py
./project_name/static/
./project_name/static/css/...
./project_name/static/js/...
./project_name/static/imgs/...
./dealer/
./dealer/admin.py
./dealer/models.py
./dealer/views.py
./dealer/urls.py
./dealer/templates/
./dealer/templates/dealer/
./dealer/templates/dealer/list.html
./vehicles/
./vehicles/admin.py
./vehicles/models.py
./vehicles/logistics/
./vehicles/logistics/models.py
./vehicles/logistics/admin.py
./vehicles/logistics/views.py
./vehicles/logistics/urls.py
./vehicles/logistics/templates/
./vehicles/logistics/templates/logistics/tracking.html
./vehicles/logistics/static/
./vehicles/logistics/static/js/app/tracking/
./vehicles/logistics/static/js/app/tracking/main.js
./vehicles/logistics/static/js/app/tracking/app.js
./vehicles/logistics/static/js/app/tracking/...
./vehicles/sales/
./vehicles/sales/models.py
./vehicles/sales/admin.py
./vehicles/sales/views.py
./vehicles/sales/urls.py
./vehicles/sales/templates/
./vehicles/sales/templates/sales/invoices.html
./vehicles/sales/static/
./vehicles/sales/static/js/app/invoices/
./vehicles/sales/static/js/app/invoices/main.js
./vehicles/sales/static/js/app/invoices/app.js
./vehicles/sales/static/js/app/invoices/...
./static/
./media/
./templates/
./templates/base.html
./templates/...

Further by analogy. If some trifle is needed, we send it to the corresponding "root" application; if a trifle becomes a more serious piece of functionality within the same subject area, we create a separate application for it inside an existing one. Everything that goes beyond the subject area is a new "root" application.

B
bromzh, 2015-10-13
@bromzh

Damn, this is Django, he himself is clearly pushing towards one application structure.
One application per 1 logical and independent part of the site. For example, an online store should include a product catalog and application functionality. Because they are interconnected. But the news part on this site should be placed in a separate application, since the news is usually almost not related to orders and goods as such.
You can also create a static folder in each application, where to put all static files. But that's what developers of "plugins" for Junga usually do. As part of the site, you can put in 1 static folder at the root of the project, but separating js and css files (so that the layout is not in the 1st super-huge css file, in which you will find what the hell). Then the collectors must collect and minimize everything.
Scatter the templates into folders, observing the hierarchy. Those. if there is a shop application, then create layout.html in the root templates folder, and put all the store templates inside templates/shop, inheriting. It is also possible to store templates inside the application, but again, this is usually used by "plugin" developers, although the principle itself is good.

F
Foo Bar, 2015-10-14
@atomheart

There is a wonderful book "Two Scoops of Django 1.8" (best practices), easy to google. The book has not been translated into Russian, but it is easy to read. It describes practical solutions to the above issues on the organization of the project and much more interesting and correct.
In general, Django allows you to reorganize the project according to a scheme convenient for the developer, and this is done quite simply.
Usually, instead of the main project folder, I make the config folder (with the settings.py file), there is also a common folder with templates (which are divided into applications), and I break the logical parts of the project into applications.
Everything looks like this:

./manage.py
./config/
./config/settings.py
./config/ursl.py
./templates/blog/
./templates/blog/base.html
./templates/blog/about.html
./templates/accounts/
./templates/accounts/login.html
./templates/accounts/registration.html
./acccounts/
./acccounts/urls.py
./acccounts/...
./blog/
./blog/urls.py
./blog/...

But I have a project where there is only a config folder, and everything else is dynamically created content.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question