1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
# About Django
Without more context, one of the technologies I recommend to everyone is Django.
Django is a Python web framework with "batteries included".
Web frameworks can provide more or less tools to write applications.
Typically, frameworks that provide fewer tools are more flexible and give developers more freedom to develop their applications in the best possible way.
Similarly, frameworks that provide more tools tend to guide you towards a specific way to writing applications, and typically, require more work if you want to deviate.
In my opinion, many applications you might need to develop are very similar and have similar issues, and solving them ad-hoc for each project is a waste.
Therefore, I lean towards using frameworks that provide more batteries in most cases.
(Certainly, there are projects that clearly need special approaches, or which deviate enough from any generic web framework.)
In fact, most of the complaints described in this document are caused by Django having too few batteries, not too many!
## The Django admin
Besides including more batteries than most other frameworks, and being in general a well-engineered framework in my opinion, Django includes the admin.
The admin is a declarative way to build administrative sites where some users edit data stored in the application database.
Many similar tools exist, but I have not found any other tool that can do so much.
* The Django admin handles multi-table relationships very well, including picking foreign key targets and editing related table data.
For example, if a person entity has a "parent" related foreign key relationship, the Django admin provides a search functionality to pick a person's parent.
If the person entity has a list of children, the Django admin provides a way to add and edit children from the person form.
* The Django admin has a simple, but useful for many scenarios permissions functionality, where editing certain entities is restricted to groups of users.
The Django admin is frequently a big boost during the early development of database-backed applications, and sometimes I can provide value during a big part of the life of an application.
Additionally, traditionally when working with frameworks without an equivalent facility, the friction of adding an interface to edit a piece of data can be large.
Developers pressed for time might opt to hardcode the data in the source code of the application, requiring code changes to modify certain behaviors of the application.
When the friction to add a user interface to edit such data is low, developers can configure the admin to let those users edit the data directly without going through the developers.
## Django problems
However, there are still many common issues for which batteries could exist, but that Django does not provide.
### Django has no support or documentation about packaging Django projects
Most Django projects have dependencies besides Django.
In order to develop and deploy Django applications, you likely must install other dependencies.
Django does not include documentation nor support to do this.
Many different approaches and tools exist to manage Python project dependencies.
Understandably, endorsing one particular approach in Django could be controversial.
So Django leaves the choice of approach up to users.
Additionally, Django adds a few difficulties in Python project management, and users must figure out how to handle Django projects in their chosen approach.
Several initiatives have tried to tackle this problem, notably:
* https://github.com/radiac/nanodjango
### Django settings are a partial solution
Django provides settings to manage the configuration for a Django project.
You implement Django settings by writing a Python module.
For example, the default Django template includes the following snippet to configure the database connection:
```
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': BASE_DIR / 'db.sqlite3',
}
}
```
Besides assigning a setting directly like in the preceding snippet, you can use Python code to assign settings.
This allows you to tackle many common issues, such as setting up a different database connection for development and production, while keeping the production database credentials away from the source code repository.
There are many similar issues that you must tackle in nearly all projects.
Several initiatives tackle some of those issues:
* https://github.com/jazzband/dj-database-url provides a way to configure the database connection through an environment variable.
### Django does not explain a development database workflow
Django provides migrations to handle schema changes.
Migrations work well and are a valid solution to handle schema changes in production.
However, while developing a Django application, you frequently need to make many temporary changes to the data definition until you find the right data definition.
In my opinion, if you follow the Django documentation, then you might end up using migrations for those development schema changes.
This is awkward and problematic, and there are procedures to develop database changes that work better.
|
