Framework basic summary
- Published: June 2, 2016
Each Django project can be composed of many apps. An app is a small project that should focus on performing one task (e.g. A website project can have: a blog, ratings, news apps).
Django project structure
A typical Django project, at first, has a very basic layout. After following
Django docs suggestions, like creating the project
$ django-admin startproject my_project and some app
$ python manage.py startapp my_app will create the following structure:
. └── mysite/ ├── manage.py ├── mysite/ | ├── __init__.py | ├── settings.py | ├── urls.py | └── wsgi.py └── myapp/ ├── __init__.py ├── admin.py ├── apps.py ├── migrations/ ├── __init__.py ├── models.py ├── tests.py ├── urls.py └── views.py
django/conf/global_settings.py, they are overwritten in
The structure that sets up Django by default is very basic, when a project starts to grow, it starts to require a better approach, outlined in Django directory structure that deals with other aspects of development and deployment such as:
- deployment scripts
- separated tests by units
- having different environments for development, production (staging)
- documentation for the project
Fat models, thin views.
In a Django web app, a form can refer to:
- an HTML form a component of a Web page that has form controls
- a Django Form that produces an HTML form
- the structured data returned when a form is submitted
- all of the above interacting together
Django handles three distinct parts of the work involved in forms
- preparing and restructuring data to make it ready for rendering
- creating HTML forms for the data
- receiving and processing submitted forms and data from the client
ModelForms are useful to:
- generate HTML
- use built-in validators approriate to each field.
A ModelForm maps fields from model classes to HTML form
<input> elements via a the Form class.
If the form is used to retrieve data, it should use the GET method, if it modifies data, it needs to use the POST method.
- Assertions available are from unittest and from Django’s TestCase so the full list of assertions available are:
The preferred way to write tests in Django is using the unittest module built in to the Python standard library
In Django we subclasses from django.test.TestCase, which is a subclass of unittest.TestCase that runs each test inside a transaction to provide isolation.
Django provides a test Client to simulate a user interacting with the code at the view level. We can use it in tests.py
- Testing tutorial https://docs.djangoproject.com/en/1.9/topics/testing/
- Edit models on the same page as a parent model with Model Inlines https://docs.djangoproject.com/en/dev/ref/contrib/admin/#inlinemodeladmin-objects
- Two Scoops Of Django
- Official Documentation in categories https://docs.djangoproject.com/en/
- Single page with links to each doc https://docs.djangoproject.com/en/1.9/contents/
*[ORM]: Object Relational Mapping