To get started:
Use the django-admin tool to generate a project folder, the basic file templates, and manage.py, which serves as your project management script.
Use manage.py to create one or more applications.
NOTE: A website may consist of one or more sections. For example, main site, blog, wiki, downloads area, etc. Django encourages you to develop these components as separate applications, which could then be re-used in different projects if desired.
Register the new applications to include them in the project.
Hook up the url/path mapper for each application.
The top-level folder structure will therefore be as follows:
locallibrary/ # Website folder
manage.py # Script to run Django tools for this project (created using django-admin)
locallibrary/ # Website/project folder (created using django-admin)
catalog/ # Application folder (created using manage.py)
The sequence of command executions is like below
mkdir django_projects
cd django_projects
Create the new project using the django-admin startproject command as shown, and then change into the project folder:
django-admin startproject locallibrary
cd locallibrary
The django-admin tool creates a folder/file structure as follows:
locallibrary/
manage.py
locallibrary/
__init__.py
settings.py
urls.py
wsgi.py
asgi.py
The locallibrary project sub-folder is the entry point for the website:
__init__.py is an empty file that instructs Python to treat this directory as a Python package.
settings.py contains all the website settings, including registering any applications we create, the location of our static files, database configuration details, etc.
urls.py defines the site URL-to-view mappings. While this could contain all the URL mapping code, it is more common to delegate some of the mappings to particular applications, as you'll see later.
wsgi.py is used to help your Django application communicate with the webserver. You can treat this as boilerplate.
asgi.py is a standard for Python asynchronous web apps and servers to communicate with each other. ASGI is the asynchronous successor to WSGI and provides a standard for both asynchronous and synchronous Python apps (whereas WSGI provided a standard for synchronous apps only). It is backward-compatible with WSGI and supports multiple servers and application frameworks.
The manage.py script is used to create applications, work with databases, and start the development web server.
Next, run the following command to create the catalog application that will live inside our locallibrary project. Make sure to run this command from the same folder as your project's manage.py:
python3 manage.py startapp catalog
The updated project directory should now look like this:
locallibrary/
manage.py
locallibrary/
catalog/
admin.py
apps.py
models.py
tests.py
views.py
__init__.py
migrations/
Copy to Clipboard
In addition we now have:
A migrations folder, used to store "migrations" — files that allow you to automatically update your database as you modify your models.
__init__.py — an empty file created here so that Django/Python will recognize the folder as a Python Package and allow you to use its objects within other parts of the project.
Open the project settings file, django_projects/locallibrary/locallibrary/settings.py, and find the definition for the INSTALLED_APPS list. Then add a new line at the end of the list, as shown below:
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
# Add our new application
'catalog.apps.CatalogConfig', #This object was created for us in /catalog/apps.py
]
Copy to Clipboard
Specifying the databases inside the settings.py
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': BASE_DIR / 'db.sqlite3',
}
}
The settings.py file is also used for configuring a number of other setting
TIME_ZONE = 'Europe/London'
SECRET_KEY. This is a secret key that is used as part of Django's website security strategy. If you're not protecting this code in development, you'll need to use a different code (perhaps read from an environment variable or file) when putting it into production.
DEBUG. This enables debugging logs to be displayed on error, rather than HTTP status code responses. This should be set to False in production as debug information is useful for attackers, but for now we can keep it set to True.
references:
https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/skeleton_website
No comments:
Post a Comment