aboutsummaryrefslogtreecommitdiff
path: root/files/tr/öğren/server-side/django/website_iskeleti/index.html
blob: 4301d37ce5e4876ef36d77613653d0ed8ad5c06a (plain)
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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
---
title: 'Django Tutorial 2. Bölüm: Websitesi İskeleti Oluşturmak'
slug: Öğren/Server-side/Django/website_iskeleti
translation_of: Learn/Server-side/Django/skeleton_website
---
<div>{{LearnSidebar}}</div>

<div>{{PreviousMenuNext("Learn/Server-side/Django/Tutorial_local_library_website", "Learn/Server-side/Django/Models", "Learn/Server-side/Django")}}</div>

<p class="summary"><a href="/en-US/docs/Learn/Server-side/Django/Tutorial_local_library_website">Django Tutorial</a> serimizin ikinci yazısında, içine siteye özgü ayarları, path'leri, model'leri, view'ları ve template'leri yerleştireceğimiz bir websitesi projesinin "iskelet"ini nasıl oluşturağınızı anlatacağız.</p>

<table class="learn-box standard-table">
 <tbody>
  <tr>
   <th scope="row">Gereksinimler:</th>
   <td><a href="/en-US/docs/Learn/Server-side/Django/development_environment">Django geliştirme ortamı kur</a><a href="/en-US/docs/Learn/Server-side/Django/Tutorial_local_library_website">Django Tutorial</a>'i gözden geçir.</td>
  </tr>
  <tr>
   <th scope="row">Amaç:</th>
   <td>Kendi website projelerinizi oluşturmak için Django araçlarını kullanabilmek</td>
  </tr>
 </tbody>
</table>

<h2 id="Genel_Bakış">Genel Bakış</h2>

<p>Bu yazıda, içine siteye özgü ayarları, path'leri, model'leri, view'ları ve template'leri(bunlardan sonra bahsedeceğiz) yerleştireceğimiz bir websitesi projesinin "iskelet"ini nasıl oluşturağınızı anlatacağız..</p>

<p>Süreç gayet açık:</p>

<ol>
 <li><code style="font-style: normal; font-weight: normal; line-height: 1.5;">django-admin</code><span style="line-height: 1.5;"> tool to create the project folder, basic file templates, and project management script (</span><strong style="line-height: 1.5;">manage.py</strong><span style="line-height: 1.5;">).</span></li>
 <li><span style="line-height: 1.5;">Use </span><strong style="line-height: 1.5;">manage.py</strong><span style="line-height: 1.5;"> to create one or more </span><em>applications</em><span style="line-height: 1.5;">.</span>
  <div class="note">
  <p><strong>Note</strong>: A website may consist of one or more sections, e.g. main site, blog, wiki, downloads area, etc. Django encourages you to develop these components as separate <em>applications</em>, which could then be re-used in different projects if desired. </p>
  </div>
 </li>
 <li><span style="line-height: 1.5;">Register the new applications to include them in the project. </span></li>
 <li><span style="line-height: 1.5;">Hook up the url/path mapper for each application.</span></li>
</ol>

<p>For the <a href="/en-US/docs/Learn/Server-side/Django/Tutorial_local_library_website">Local Library website</a> the website folder and its project folder will be named <em>locallibrary</em>, and we'll have just one application named <em>catalog</em>. The top level folder structure will therefore be as follows:</p>

<pre class="brush: bash"><em>locallibrary/         # Website folder</em>
    <strong>manage.py         </strong># Script to run Django tools for this project (created using django-admin)
    <em>locallibrary/     # Website/project folder </em>(created using django-admin)
    <em>catalog/          # Application folder </em>(created using manage.py)
</pre>

<p><span style="line-height: 1.5;">The following sections discuss the process steps in detail, and show how you can test the changes. At the end of the article we discuss some of the other site-wide configuration you might also do at this stage.</span></p>

<h2 id="Projeyi_Oluşturma">Projeyi Oluşturma</h2>

<p>İlk olarak komut istemi/terminali açın,  <a href="/en-US/docs/Learn/Server-side/Django/development_environment#Using_a_virtual_environment">sanal ortamda</a> olduğunuza emin olun, Django uygulamalarının bulunmasını istediğiniz yeri açın(<code>cd</code> komutuyla)<span style="line-height: 1.5;"> (<em>belgeler </em>klasörü gibi kolay bulabileceğiniz bir yer olsun) ve  yeni websiteniz için yeni bir klasör oluşturun (biz </span><em>django_projects </em>olarak oluşturduk). Sonra <code>cd</code> komutuyla o klasöre girin:</p>

<pre class="brush: bash">mkdir django_projects
cd django_projects</pre>

<p>Gösterildiği gibi <code>django-admin startproject</code> komutuyla yeni projeyi oluşturun ve sonra klasörün içine girin.</p>

<pre class="brush: bash">django-admin startproject locallibrary
cd locallibrary</pre>

<p><code>django-admin</code> aracı aşağıda görünen şekilde bir klasör/dosya yapısı oluşturur:</p>

<pre class="brush: bash"><em>locallibrary/</em>
    manage.py
    <em>locallibrary/</em>
        __init__.py
        settings.py
        urls.py
        wsgi.py</pre>

<p>Bizim çalıştığımız klasör şuna benzer şekilde görünmeli:</p>

<pre class="syntaxbox">../django_projects/locallibrary/</pre>

<p><em>locallibrary</em> proje altklasörü websitemiz için giriş noktası:</p>

<ul>
 <li><strong>__init__.py </strong>Python'a bu klasöre Python paketi olarak davranması gerektiğini söyleyen boş bir dosya.</li>
 <li><strong>settings.py</strong> tüm website ayarlarının olduğu dosya. Buraya oluşturduğumuz uygulamaları, static dosyalarımızın bulunduğu yeri, veritabanı ayarlarını vs. kaydederiz.  </li>
 <li><strong>urls.py</strong> sitemizin url-view eşlemelerinin tanımladığımız yer. Burada tüm url eşlemelerini tanımlayabilsek de bazı eşlemeleri ileride göreceğimiz gibi uygulamalara bölmek daha yaygın kullanılır<span style="line-height: 1.5;">. </span></li>
 <li><strong style="line-height: 1.5;">wsgi.py</strong><span style="line-height: 1.5;"> Django uygulamamızın web sunucusuyla iletişim kurmasına yardım eder. Şablon olarak düşünebilirsiniz.</span></li>
</ul>

<p><strong>manage.py</strong> betiği(script) uygulama oluşturmakta, veritabanı işlemlerinde ve geliştirme ortamı sunucusunu(yerel sunucu: 127.0.0.1:8000) başlatmakta kullanılır. </p>

<h2 id="Catalog_uygulamasını_oluşturma">Catalog uygulamasını oluşturma</h2>

<p><em>locallibrary </em>projemizin içinde duracak olan <em>catalog</em> uygulamasını oluşturmak için aşağıdaki komutu çalıştırın (projemizin <strong>manage.py </strong>betiğinin de bulunduğu klasörde çalıştırılmalı):</p>

<pre class="brush: bash">python3 manage.py startapp catalog</pre>

<div class="note">
<p><strong>Not</strong>: Yukarıdaki komut Linux/macOS X içindir. Windows'taki komut şu şekilde olmalı: <code>py -3 manage.py startapp catalog</code></p>

<p>Windows kullanıyorsanız, bu modül boyunca <code>python3</code> yerine  <code>py -3</code> yazmalısınız.</p>

<p>Python 3.7.0 kullanıyorsanız sadece  <code>py manage.py startapp catalog</code> kullanmalısınız.</p>
</div>

<p>Bu araç yeni bir klasör oluşturup içini uygulamamızın muhtelif kısımları için kullanılacak dosyalarla(aşağıda kalın olarak yazıldı) doldurur. Dosyaların çoğu amaçlarına uygun olarak isimlendirilmiştir (mesela view'lar <strong>views.py'</strong>da, Model'ler <strong>models.py'</strong>da, test'ler <strong>tests.py'</strong>da, site yönetim sayfası ayarları <strong>admin.py'</strong>da, uygulama kayıtları <strong>apps.py'</strong>da bulunur). Ayrıca bu dosyalar ilişkili oldukları nesnelerle çalışırken kullanılabilecek minimal bir kod şablonu da içerir.</p>

<p>Proje klasörünün son hali şu şekilde görünmeli:</p>

<pre class="brush: bash"><em>locallibrary/</em>
    manage.py
    <em>locallibrary/
</em><strong>    <em>catalog/</em>
        admin.py
        apps.py
        models.py
        tests.py
        views.py
        __init__.py
        <em>migrations/</em></strong>
</pre>

<p>In addition we now have:</p>

<ul>
 <li>A <em>migrations</em> folder, used to store "migrations" — files that allow you to automatically update your database as you modify your models. </li>
 <li><strong>__init__.py</strong> — an empty file created here so that Django/Python will recognise the folder as a <a href="https://docs.python.org/3/tutorial/modules.html#packages">Python Package</a> and allow you to use its objects within other parts of the project.</li>
</ul>

<div class="note">
<p><strong>Note</strong>: Have you noticed what is missing from the files list above? While there is a place for your views and models, there is nowhere for you to put your url mappings, templates, and static files. We'll show you how to create them further along (these aren't needed in every website but they are needed in this example).</p>
</div>

<h2 id="Registering_the_catalog_application">Registering the catalog application</h2>

<p>Now that the application has been created we have to register it with the project so that it will be included when any tools are run (for example to add models to the database). Applications are registered by adding them to the <code>INSTALLED_APPS</code> list in the project settings. </p>

<p>Open the project settings file <strong>django_projects/locallibrary/locallibrary/settings.py</strong> and find the definition for the <code>INSTALLED_APPS</code> list. Then add a new line at the end of the list, as shown in bold below.</p>

<pre class="brush: bash">INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
<strong>    'catalog.apps.CatalogConfig', </strong>
]</pre>

<p>The new line specifies the application configuration object (<code>CatalogConfig</code>) that was generated for you in <strong>/locallibrary/catalog/apps.py</strong> when you created the application.</p>

<div class="note">
<p><strong>Note</strong>: You'll notice that there are already a lot of other <code>INSTALLED_APPS</code> (and <code>MIDDLEWARE</code>, further down in the settings file). These enable support for the <a href="/en-US/docs/Learn/Server-side/Django/Admin_site">Django administration site</a> and as a result lots of the functionality it uses (including sessions, authentication, etc).</p>
</div>

<h2 id="Specifying_the_database">Specifying the database</h2>

<p>This is also the point where you would normally specify the database to be used for the project — it makes sense to use the same database for development and production where possible, in order to avoid minor differences in behaviour.  You can find out about the different options in <a href="https://docs.djangoproject.com/en/2.0/ref/settings/#databases">Databases</a> (Django docs). </p>

<p>We'll use the SQLite database for this example, because we don't expect to require a lot of concurrent access on a demonstration database, and also because it requires no additional work to set up! You can see how this database is configured in <strong>settings.py</strong> (more information is also included below):</p>

<pre class="brush: python">DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}
</pre>

<p>Because we are using SQLite, we don't need to do any further setup here. Let's move on!</p>

<h2 id="Other_project_settings">Other project settings</h2>

<p>The <strong>settings.py</strong> file is also used for configuring a number of other settings, but at this point you probably only want to change the <a href="https://docs.djangoproject.com/en/2.0/ref/settings/#std:setting-TIME_ZONE">TIME_ZONE</a> — this should be made equal to a string from the standard <a href="https://en.wikipedia.org/wiki/List_of_tz_database_time_zones">List of tz database time zones</a> (the TZ column in the table contains the values you want). Change your <code>TIME_ZONE</code> value to one of these strings appropriate for your time zone, for example:</p>

<pre class="brush: python">TIME_ZONE = 'Europe/London'</pre>

<p>There are two other settings you won't change now, but that you should be aware of:</p>

<ul>
 <li><code>SECRET_KEY</code>. 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. </li>
 <li><code>DEBUG</code>. This enables debugging logs to be displayed on error, rather than HTTP status code responses. This should be set to <code>False</code> on production as debug information is useful for attackers, but for now we can keep it set to <code>True</code>.</li>
</ul>

<h2 id="Hooking_up_the_URL_mapper">Hooking up the URL mapper</h2>

<p>The website is created with a URL mapper file (<strong>urls.py</strong>) in the project folder. While you can use this file to manage all your URL mappings, it is more usual to defer mappings to the associated application.</p>

<p>Open <strong>locallibrary/locallibrary/urls.py</strong> and note the instructional text which explains some of the ways to use the URL mapper. </p>

<pre class="brush: python">"""locallibrary URL Configuration

The `urlpatterns` list routes URLs to views. For more information please see:
    https://docs.djangoproject.com/en/2.0/topics/http/urls/
Examples:
Function views
    1. Add an import:  from my_app import views
    2. Add a URL to urlpatterns:  path('', views.home, name='home')
Class-based views
    1. Add an import:  from other_app.views import Home
    2. Add a URL to urlpatterns:  path('', Home.as_view(), name='home')
Including another URLconf
    1. Import the include() function: from django.urls import include, path
    2. Add a URL to urlpatterns:  path('blog/', include('blog.urls'))
"""
from django.contrib import admin
from django.urls import path

urlpatterns = [
    path('admin/', admin.site.urls),
]
</pre>

<p>The URL mappings are managed through the <code>urlpatterns</code> variable, which is a Python <em>list</em> of <code>path()</code> functions. Each <code>path()</code> function either associates a URL pattern to a <em>specific view</em>, which will be displayed when the pattern is matched, or with another list of URL pattern testing code (in this second case, the pattern becomes the "base URL" for patterns defined in the target module). The <code>urlpatterns</code> list initially defines a single function that maps all URLs with the pattern <em>admin/</em> to the module <code>admin.site.urls</code> , which contains the Administration application's own URL mapping definitions.</p>

<div class="note">
<p><strong>Note</strong>: The route in <code>path()</code> is a string defining a URL pattern to match. This string might include a named variable (in angle brackets), e.g. <code>'catalog/&lt;id&gt;/'</code>. This pattern will match a URL like <strong>/catalog/</strong><em>any_chars</em><strong>/</strong> and pass <em>any_chars</em> to the view as a string with parameter name <code>id</code>). We discuss path methods and route patterns further in later topics.</p>
</div>

<p>Add the lines below to the bottom of the file in order to add a new list item to the <code>urlpatterns</code> list. This new item includes a <code>path()</code> that forwards requests with the pattern <code>catalog/</code> to the module <code>catalog.urls</code> (the file with the relative URL <strong>/catalog/urls.py</strong>).</p>

<pre class="brush: python"># Use include() to add paths from the catalog application
from django.conf.urls import include
from django.urls import path

urlpatterns += [
    path('catalog/', include('catalog.urls')),
]
</pre>

<p>Now let's redirect the root URL of our site (i.e. <code>127.0.0.1:8000</code>) to the URL <code>127.0.0.1:8000/catalog/</code>; this is the only app we'll be using in this project, so we might as well. To do this, we'll use a special view function (<code>RedirectView</code>), which takes as its first argument the new relative URL to redirect to (<code>/catalog/</code>) when the URL pattern specified in the <code>path()</code> function is matched (the root URL, in this case).</p>

<p>Add the following lines, again to the bottom of the file:</p>

<pre class="brush: python">#Add URL maps to redirect the base URL to our application
from django.views.generic import RedirectView
urlpatterns += [
    path('', RedirectView.as_view(url='/catalog/')),
]</pre>

<p>Leave the first parameter of the path function empty to imply '/'. If you write the first parameter as '/' Django will give you the following warning when you start the development server:</p>

<pre class="brush: python">System check identified some issues:

WARNINGS:
?: (urls.W002) Your URL pattern '/' has a route beginning with a '/'.
Remove this slash as it is unnecessary.
If this pattern is targeted in an include(), ensure the include() pattern has a trailing '/'.
</pre>

<p>Django does not serve static files like CSS, JavaScript, and images by default, but it can be useful for the development web server to do so while you're creating your site. As a final addition to this URL mapper, you can enable the serving of static files during development by appending the following lines. </p>

<p>Add the following final block to the bottom of the file now:</p>

<pre><code># Use static() to add url mapping to serve static files during development (only)
from django.conf import settings
from django.conf.urls.static import static

urlpatterns += static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)</code>
</pre>

<div class="note">
<p><strong>Note</strong>: There are a number of ways to extend the <code>urlpatterns</code> list (above we just appended a new list item using the <code>+=</code> operator to clearly separate the old and new code). We could have instead just included this new pattern-map in the original list definition:</p>

<pre class="brush: python">urlpatterns = [
    path('admin/', admin.site.urls),
    path('catalog/', include('catalog.urls')),
    path('', RedirectView.as_view(url='/catalog/', permanent=True)),
] + <code>static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)</code>
</pre>

<p>In addition, we included the import line (<code>from django.urls import include</code>) with the code that uses it (so it is easy to see what we've added), but it is common to include all your import lines at the top of a Python file.</p>
</div>

<p>As a final step, create a file inside your catalog folder called <strong>urls.py</strong>, and add the following text to define the (empty) imported <code>urlpatterns</code>. This is where we'll add our patterns as we build the application. </p>

<pre class="brush: python">from django.urls import path
from catalog import views


urlpatterns = [

]
</pre>

<h2 id="Testing_the_website_framework">Testing the website framework</h2>

<p>At this point we have a complete skeleton project. The website doesn't actually <em>do</em> anything yet, but its worth running it to make sure that none of our changes have broken anything. </p>

<p>Before we do that, we should first run a <em>database migration</em>. This updates our database to include any models in our installed applications (and removes some build warnings).</p>

<h3 id="Running_database_migrations">Running database migrations</h3>

<p>Django uses an Object-Relational-Mapper (ORM) to map Model definitions in the Django code to the data structure used by the underlying database. As we change our model definitions, Django tracks the changes and can create database migration scripts (in <strong>/locallibrary/catalog/migrations/</strong>) to automatically migrate the underlying data structure in the database to match the model.</p>

<p>When we created the website Django automatically added a number of models for use by the admin section of the site (which we'll look at later). Run the following commands to define tables for those models in the database (make sure you are in the directory that contains<strong> manage.py</strong>):</p>

<pre class="brush: bash">python3 manage.py makemigrations
python3 manage.py migrate
</pre>

<div class="warning">
<p><strong>Important</strong>: You'll need to run the above commands every time your models change in a way that will affect the structure of the data that needs to be stored (including both addition and removal of whole models and individual fields).</p>
</div>

<p>The <code>makemigrations</code> command <em>creates</em> (but does not apply) the migrations for all applications installed in your project (you can specify the application name as well to just run a migration for a single project). This gives you a chance to checkout the code for these migrations before they are applied — when you're a Django expert you may choose to tweak them slightly!</p>

<p>The <code>migrate</code> command actually applies the migrations to your database (Django tracks which ones have been added to the current database).</p>

<div class="note">
<p><strong>Note</strong>: See <a href="https://docs.djangoproject.com/en/2.0/topics/migrations/">Migrations</a> (Django docs) for additional information about the lesser-used migration commands.</p>
</div>

<h3 id="Running_the_website">Running the website</h3>

<p>During development you can test the website by first serving it using the <em>development web server</em>, and then viewing it on your local web browser. </p>

<div class="note">
<p><strong>Note</strong>: The development web server is not robust or performant enough for production use, but it is a very easy way to get your Django website up and running during development to give it a convenient quick test. By default it will serve the site to your local computer (<code>http://127.0.0.1:8000/)</code>, but you can also specify other computers on your network to serve to. For more information see <a href="https://docs.djangoproject.com/en/2.0/ref/django-admin/#runserver">django-admin and manage.py: runserver</a> (Django docs).</p>
</div>

<p>Run the <em>development web server</em> by calling the <code>runserver</code> command (in the same directory as <strong>manage.py</strong>):</p>

<pre class="brush: bash">python3 manage.py runserver

 Performing system checks...

 System check identified no issues (0 silenced).
 August 15, 2018 - 16:11:26
 Django version 2.1, using settings 'locallibrary.settings'
 Starting development server at http://127.0.0.1:8000/
 Quit the server with CTRL-BREAK.
</pre>

<p>Once the server is running you can view the site by navigating to <code>http://127.0.0.1:8000/</code> in your local web browser. You should see a site error page that looks like this:</p>

<p><img alt="Django Debug page for Django 2.0" src="https://mdn.mozillademos.org/files/15729/django_404_debug_page.png"></p>

<p>Don't worry! This error page is expected because we don't have any pages/urls defined in the <code>catalogs.urls</code> module (which we're redirected to when we get an URL to the root of the site). </p>

<div class="note">
<p><strong>Note</strong>: The above page demonstrates a great Django feature — automated debug logging. An error screen will be displayed with useful information whenever a page cannot be found, or any error is raised by the code. In this case we can see that the URL we've supplied doesn't match any of our URL patterns (as listed). The logging will be turned off during production (when we put the site live on the Web), in which case a less informative but more user-friendly page will be served.</p>
</div>

<p>At this point we know that Django is working! </p>

<div class="note">
<p><strong>Note</strong>: You should re-run migrations and re-test the site whenever you make significant changes. It doesn't take very long!</p>
</div>

<h2 id="Challenge_yourself">Challenge yourself</h2>

<p>The <strong>catalog/</strong> directory contains files for the views, models, and other parts of the application. Open these files and inspect the boilerplate. </p>

<p>As you saw above, a URL-mapping for the Admin site has already been added in the project's <strong>urls.py</strong>. Navigate to the admin area in your browser and see what happens (you can infer the correct URL from the mapping above).</p>

<ul>
</ul>

<h2 id="Summary">Summary</h2>

<p>You have now created a complete skeleton website project, which you can go on to populate with urls, models, views, and templates.</p>

<p>Now the skeleton for the <a href="/en-US/docs/Learn/Server-side/Django/Tutorial_local_library_website">Local Library website</a> is complete and running, it's time to start writing the code that makes this website do what it is supposed to do. </p>

<h2 id="See_also">See also</h2>

<ul>
 <li><a href="https://docs.djangoproject.com/en/2.0/intro/tutorial01/">Writing your first Django app - part 1</a>  (Django docs)</li>
 <li><a href="https://docs.djangoproject.com/en/2.0/ref/applications/#configuring-applications">Applications</a> (Django Docs). Contains information on configuring applications.</li>
</ul>

<p>{{PreviousMenuNext("Learn/Server-side/Django/Tutorial_local_library_website", "Learn/Server-side/Django/Models", "Learn/Server-side/Django")}}</p>

<p> </p>

<h2 id="In_this_module">In this module</h2>

<ul>
 <li><a href="/en-US/docs/Learn/Server-side/Django/Introduction">Django introduction</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/Django/development_environment">Setting up a Django development environment</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/Django/Tutorial_local_library_website">Django Tutorial: The Local Library website</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/Django/skeleton_website">Django Tutorial Part 2: Creating a skeleton website</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/Django/Models">Django Tutorial Part 3: Using models</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/Django/Admin_site">Django Tutorial Part 4: Django admin site</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/Django/Home_page">Django Tutorial Part 5: Creating our home page</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/Django/Generic_views">Django Tutorial Part 6: Generic list and detail views</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/Django/Sessions">Django Tutorial Part 7: Sessions framework</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/Django/Authentication">Django Tutorial Part 8: User authentication and permissions</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/Django/Forms">Django Tutorial Part 9: Working with forms</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/Django/Testing">Django Tutorial Part 10: Testing a Django web application</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/Django/Deployment">Django Tutorial Part 11: Deploying Django to production</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/Django/web_application_security">Django web application security</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/Django/django_assessment_blog">DIY Django mini blog</a></li>
</ul>

<p> </p>