text: This translation is incomplete. この記事の翻訳にご協力ください
  Djangoチュートリアル の2つ目の記事では、基本的なウェブサイトプロジェクトの「スケルトン」をどのように作っていくのかを説明します。サイト固有の設定、URL、モデル、ビュー、テンプレートを作成する方法について説明します。
  概要. 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.
  For the Local Library website the website folder and its project folder will be named locallibrary, and we'll have just one application named catalog. 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 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.
  プロジェクトの作成.
  catalogアプリケーションの作成.
  If you are using Python 3.7.0, you should only use
  py manage.py startapp catalog
  The tool creates a new folder and populates it with files for the different parts of the application (shown in bold below). Most of the files are usefully named after their purpose (e.g. views should be stored in views.py, Models in models.py, tests in tests.py, administration site configuration in admin.py, application registration in apps.py) and contain some minimal boilerplate code for working with the associated objects.
  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/
  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 recognise the folder as a Python Package and allow you to use its objects within other parts of the project.
  Note: 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).
  catalogアプリケーションの登録
  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 ', ]
  The new line specifies the application configuration object (
  CatalogConfig) that was generated for you in /locallibrary/catalog/apps.py when you created the application.
  Note: You'll notice that there are already a lot of other
  INSTALLED_APPS (and
  MIDDLEWARE, further down in the settings file). These enable support for the Django administration site and as a result lots of the functionality it uses (including sessions, authentication, etc).
  データベースの指定
  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):
  DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': os.path.join(BASE_DIR, 'db.sqlite3'), } }
  Because we are using SQLite, we don't need to do any further setup here. Let's move on!
  その他のプロジェクト設定
  The settings.py file is also used for configuring a number of other settings, but at this point you probably only want to change the TIME_ZONE — this should be made equal to a string from the standard List of tz database time zones (the TZ column in the table contains the values you want). Change your
  TIME_ZONE value to one of these strings appropriate for your time zone, for example:
  TIME_ZONE = 'Europe/London'
  There are two other settings you won't change now, but that you should be aware of:
  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
  Falseon production as debug information is useful for attackers, but for now we can keep it set to
  True.
  URLマッパーの接続
  The website is created with a URL mapper file (urls.py) 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.
  Open locallibrary/locallibrary/urls.py and note the instructional text which explains some of the ways to use the URL mapper.
  """locallibrary urlpatterns = [ path('admin/', admin.site.urls), ]
  The URL mappings are managed through the
  urlpatterns variable, which is a Python list of
  path() functions. Each
  path() function either associates a URL pattern to a specific view, 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
  urlpatterns list initially defines a single function that maps all URLs with the pattern admin/ to the module
  admin.site.urls , which contains the Administration application's own URL mapping definitions.
  Note: The route in
  path() is a string defining a URL pattern to match. This string might include a named variable (in angle brackets), e.g.
  'catalog/<id>/'. This pattern will match a URL like /catalog/any_chars/ and pass any_chars to the view as a string with parameter name
  id). We discuss path methods and route patterns further in later topics.('catalog/', include('catalog.urls')), ]/')), ]
  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:
  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 '/'.
  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.
  Add the following final block to the bottom of the file now:
  # 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)
  Note: There are a number of ways to extend the
  urlpatterns list (above we just appended a new list item using the
  += operator to clearly separate the old and new code). We could have instead just included this new pattern-map in the original list definition:
  urlpatterns = [ path('admin/', admin.site.urls), path('catalog/', include('catalog.urls')), path('', RedirectView.as_view(url='/catalog/',.
  As a final step, create a file inside your catalog folder called urls.py, and add the following text to define the (empty) imported
  urlpatterns. This is where we'll add our patterns as we build the application.
  from django.urls import path from . import views urlpatterns = [ ]
  ウェブサイトフレームワークのテスト
  At this point we have a complete skeleton project. The website doesn't actually do anything yet, but its worth running it to make sure that none of our changes have broken anything.
  Before we do that, we should first run a database migration. This updates our database to include any models in our installed applications (and removes some build warnings).
  Running database migrations
  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 /locallibrary/catalog/migrations/) to automatically migrate the underlying data structure in the database to match the model.
  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 manage.py):
  python3 manage.py makemigrations python3 manage.py migrate
  Important: 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).
  The
  makemigrations command creates (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 using the development web server, and then viewing it on your local web browser.
  Note: 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 (), but you can also specify other computers on your network to serve to. For more information see django-admin and manage.py: runserver (Django docs).
  Run the development web server by calling the
  runserver command (in the same directory as manage.py):
  python3 manage.py runserver Performing system checks... System check identified no issues (0 silenced). September 22, 2016 - 16:11:26 Django version 1.10, using settings 'locallibrary.settings' Starting development server at Quit the server with CTRL-BREAK.
  Once the server is running you can view the site by navigating to in your local web browser. You should see a site error page that looks like this:
  Don't worry! This error page is expected because we don't have any pages/urls defined in the
  catalogs (when we put the site live on the Web), in which case a less informative but more user-friendly page will be served.
  At this point we know that Django is working!
  Note: You should re-run migrations and re-test the site whenever you make significant changes. It doesn't take very long!
  自分でやってみよう
  The catalog/ directory contains files for the views, models, and other parts of the application. Open these files and inspect the boilerplate.
  As you saw above, a URL-mapping for the Admin site has already been added in the project's urls.py. Navigate to the admin area in your browser and see what happens (you can infer the correct URL from the mapping above).
  要約
  You have now created a complete skeleton website project, which you can go on to populate with urls, models, views, and templates.
  Now the skeleton for the Local Library website is complete and running, it's time to start writing the code that makes this website do what it is supposed to do.
  参考文献
  - Writing your first Django app - part 1 (Django docs)
  - Applications (Django Docs). Contains information on configuring applications.
  このモジュール内
  -