contenttypes フレームワーク — Django 1.4 documentation
Django には、 contenttypes アプリケーションが付属しています。 このアプリケーションを使うと、 Django で作成したプロジェクト中に存在する全 てのモデルを追跡できます。また、 contenttypes では、モデルを扱うための 高水準かつ汎用的なインタフェースを提供しています。 概要¶ contenttypes アプリケーションの心臓部は、 django.contrib.contenttypes.models で定義されている ContentType モデルです。 django.contrib.contenttypes.models.ContentType のインスタンスは、 プロジェクト上にインストールされているモデルの情報を表現したり保存したりし ています。 ContentType のイン スタンスは、新たにモデルをインストールすると自動的に生成されます。 C
フォームやフィールドのバリデーション — Django 1.4 documentation
フォームのバリデーションは、データのクリーニングを行ったときに実行されます。 この挙動をカスタマイズしたければ、目的に応じていくつかの手法から選択するこ とになります。フォームの処理では、 3 つのデータクリーニング過程があります。 これらの過程は通常、フォームの is_valid() メソッドを呼び出したときに実 行されます。データのクリーニングとバリデーションをトリガする要素は他にもあ ります (errors 属性へのアクセスや、 full_clean() の呼び出し) が、 通常は直接用いることはありません。 一般に、データクリーニングのメソッドは、処理中のデータに何らかの問題がある 場合、 ValidationError 例外を送出し、その際 ValidationError のコン ストラクタにエラーメッセージを渡すことになっています。 ValidationError を送出しない
ビューのデコレータ — Django 1.4 documentation
ビューのデコレータ¶ Django には、HTTP の様々な機能をビューに適用するためのいくつかのデコレータ が用意されています。 HTTP メソッドの制限¶ django.views.decorators.http 内の以下のデコレータはリクエストメソッド によるアクセス制限に使用できます。このデコレータは、条件を満たしていない 場合 django.http.HttpResponseNotAllowed を返します。 require_http_methods(request_method_list)¶ 特定のリクエストメソッドのみを許可するためのデコレータの利用方法です: from django.views.decorators.http import require_http_methods @require_http_methods(["GET", "POST"]) def my_v
モデルの Meta オプション — Django 1.4 documentation
テーブル名¶ ユーザの手間を省くため、 Django はモデルクラスやアプリケーションの名前を 元にデータベーステーブルの名前を導出します。モデルのデータベーステーブル名は、 モデルの「アプリケーションラベル (app label)」、つまり manage.py startapp で指定した名前と、モデルのクラス名をアンダースコアで 結んで生成します。 例えば、 (manage.py startapp bookstore で作成した) bookstore という アプリケーションの中に class Book で定義したモデルがあった場合その データベーステーブルの名前は bookstore_book です。 データベーステーブル名をオーバライドしたければ、 class Meta に db_table パラメタを設定します。 データベーステーブル名が SQL の予約語と一致している場合や、ハ
ビューを書く — Django 1.4 documentation
ビュー関数、あるいは単に ビュー とは、簡単にいえばウェブリクエストを引数 にとり、ウェブレスポンスを返す関数です。レスポンスはウェブページを表す HTML コンテンツでもよいし、リダイレクトでも、 404 エラーでも、 XML ドキュメント でも、画像でも、何でもかまいません。ビューの中には、レスポンスを生成する上 で必要なロジックを自由に書けます。ビューのコードは、 Python パス上にあるか ぎり、どこに置いてもかまいません。他にはなんの制限も「黒魔術」もありません。 慣習では、 プロジェクトディレクトリかアプリケーションディレクトリの下に views.py という名前のファイルを作成して、そこにビューのコードを置くこと になっています。 from django.http import HttpResponse import datetime def current_datetim
データベーストランザクションの管理 — Django 1.4 documentation
Django はトランザクションをサポートしているデータベース向けに、トランザクショ ン管理を制御する方法をいくつか提供しています。 デフォルトのトランザクション処理¶ Django のデフォルトの挙動では、組み込みのデータ変更に関わるモデル関数を呼び 出したときにはいつでも自動的に commit を行います。例えば、 model.save() や model.delete() を呼び出すと、変更は即座にコミットされます。 これはほとんどのデータベースにおける自動コミット設定とほとんど同じ挙動です。 すなわち、ユーザがデータベースへの書き込みを必要とするような操作を行うと、 Django はすぐに INSERT/UPDATE/DELETE 文を実行し、次いで COMMIT を実行します。暗黙のロールバックは行いません。 HTTP リクエストとトランザクションを結び付ける¶ Transact
Django admin サイト — Django 1.4 documentation
Django の最も強力な機能の一つに、自動生成される admin インタフェースがあり ます。 admin はモデルのメタデータを読み込んで、強力で実運用に耐えるインタ フェースを生成し、コンテンツの製作者がすぐにサイトにコンテンツを投入できる ようにします。このドキュメントでは、 Django の admin インタフェースを有効に したり、カスタマイズしたりする方法を解説します。 注意 admin サイトは Django 0.96 から大幅にリファクタされました。このドキュメ ントでは、よりカスタマイズ機能の充実した新しい admin サイトについて解説 しています。この admin サイトの仕様は、 Django の開発をよく追いかけてい る人なら、一度は “newforms-admin” という名前で耳にしたことがあるはずで す。 django.contrib.admin を I
テンプレートタグやフィルタを自作する — Django 1.4 documentation
Django テンプレートシステムには、いろいろな 組み込みタグとフィルタ が付属していて、アプリケーションのプレゼンテーショ ンロジックにまつわる問題を解決できます。とはいえ、コアのテンプレートタグプリミ ティブだけでは、要求を満たせない場合もあります。そういう場合のために、テンプ レートエンジンを拡張できます。Python で自作のタグやフィルタを書き、テンプレー ト上で {% load %} タグを使って使えるのです。 コードの配置¶ カスタムのテンプレートタグやフィルタは Django のアプリケーション内に置きま す。既存のアプリケーションに関連があるのなら、そのアプリケーションにバンド ルすればよいでしょう。そうでなければ、コードを入れておくための新たなアプリ ケーションを作成します。 アプリケーション内には、 templatetags ディレクトリを置かねばなりません。 この
Django でのユーザ認証 — Django 1.4 documentation
Django にはユーザ認証システムがついてきます。 Django のユーザ認証システムは、 ユーザアカウント、グループ、パーミッションとクッキーベースのユーザセッショ ンを扱えます。このドキュメントでは、ユーザ認証の仕組みについて説明します。 概要¶ 認証システムは以下の要素から成り立っています: ユーザ (Users) パーミッション: あるユーザが特定のタスクを実行してよいかどうかを決め る、バイナリ (yes/no) のフラグです。 グループ (Groups): 複数のユーザに対してラベル付したり、認証を設定した りするための一般的な方法です。 メッセージ (Messages): 指定のユーザ(達) に対するメッセージをキューす るための簡単な方法です。 インストール¶ 認証のサポートは Django アプリケーションとして django.contrib.auth にバ ンドルされ
モデルの作成 — Django 1.4 documentation
モデルとは、サイトを構成するデータの、唯一絶対的なデータソースを指します。 モデルには、保存したいデータを表すデータフィールドと、データのビヘイビアを 定義します。通常、一つのモデルは一つのデータベーステーブルに対応しています。 モデルの基本として、以下のことを知っておいてください: 各モデルは Python のクラスで、 django.db.models.Model のサブ クラスです。 モデルの各アトリビュートの値は、データベース上のあるフィールドを表現 します。 モデルの情報をもとに、 Django はデータベース API を自動生成します。 API の詳細は「 クエリを生成する 」で解説します。 from django.db import models class Person(models.Model): first_name = models.CharField(max_len
はじめての Django アプリ作成、その 1 — Django 1.4 documentation
さあ、例を交えながら学んでゆきましょう。 このチュートリアルでは、簡単な投票 (poll) アプリケーションの作成に取り組ん でもらいます。 Poll アプリケーションは、 ユーザが投票したり結果を表示したりできる公開用サイト 投票項目の追加、変更、削除を行うための管理 (admin) サイト の二つの部分に分かれています。 Django は既にインストール済み として、説明を進めます。 Django がインストールされているかどうかは、Python 対話シェルを起動して import django を実行してみればわかります。エラーなく import できるなら、 Django はインストールされています。 困ったときは: このチュートリアルを進めてゆく上で困ったことがあったら、 django-users や irc.freenode.net の #djangoチャネル で誰か助けてくれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Django のキャッシュフレームワーク — Django 1.4 documentation
フォームセット (formsets) — Django 1.4 documentation
メールの送信 — Django 1.4 documentation
uWSGI で Django を使う方法 — Django 1.4 documentation
静的ファイルの公開方法 — Django 1.4 documentation
古いデータベースを Django に組み込む — Django 1.4 documentation