Django Advent Calendar 2016 12日目の記事です。
はじめに
PythonのWebフレームワークであるDjangoは管理サイトが神ってることが特徴の一つです。
上のようなフィルターやテキスト検索、ソート、ページングなどを備えた一覧画面と登録・編集画面が以下のような数行の宣言的なコードだけで実現できてしまいます。
@admin.register(Question)
class QuestionAdmin(admin.ModelAdmin):
list_display = ('question_text', 'pub_date', 'was_published_recently')
list_filter = ['pub_date']
search_fields = ['question_text']
これを使えばWebアプリの構築がすごく簡単にできるように思ってしまいますが、管理サイトには色々と制約があるので、過度に期待してはいけません。
管理サイトは用途限定
まず、管理サイトはその名の通り管理者向けのサイトとして設計されています。
ここでいう管理者とは、システム管理者、サービス運用者などのいわゆる中の人のことです。
管理サイトでは各モデルの一覧・登録・編集画面を提供しますが、これは管理者向けの機能であって一般ユーザーに公開するものではありません。
一般ユーザーがデータの閲覧・更新を行う画面が必要な場合は、管理サイトではなく通常の画面(以下、一般サイトと呼びます)で作成する必要があります。
例えば記事を閲覧・登録できるWebアプリを構築する場合を考えてみます。
記事を分類するカテゴリーをサービス運用者が予め登録するのであれば、それは管理サイトで作ってもいいでしょう。
しかし、一般ユーザーが使用する記事の閲覧・登録画面は一般サイトとして作ることになります。
サイト別にユースケースの例を挙げるとこんな感じです。
- 一般サイト
- 一般ユーザーが、アカウントを登録する
- 一般ユーザーが、記事を閲覧する
- 一般ユーザーが、記事を投稿する
- 管理サイト
- システム管理者、サービス運用者が、管理者アカウントを登録する
- サービス運用者が、カテゴリーを登録する
- サービス運用者が、一般ユーザーのアカウントを停止する
- サービス運用者が、規約違反の記事を削除する
基本の画面構成は固定
管理サイトの主要画面は、トップメニューと各モデルの一覧・登録・編集画面から構成されています。
トップメニューはアプリケーション(startappで作るやつ)でグルーピングされてモデルへのリンクで構成されています。
モデルの画面にカスタムアクション(画面)を追加することはできますが、元の画面構成を大きく変えるようなことはできません。
管理サイトの機能は一般サイトには組み込めない
管理サイトの一覧画面には以下のような便利な機能が予め組み込まれています。
- ページング
- ソート
- フィルター
一般サイトでもこれらの機能はほぼ確実に必要になるでしょう。
しかし残念ながら管理サイトの機能を一般サイトで流用することはできません。自分で作る必要があります。
クラスベースViewでは管理サイトの機能とは別にページング・ソート・フィルターの実装を補助するものは提供されているので実装は容易ですが、それでもテンプレートは全く用意されていないので自分で書く必要があります。
想定されたカスタマイズ以上のことは難しい・出来ない可能性がある
管理サイトでは簡単なカスタマイズであればAdminクラスでコードを1行追加だけで実現できます。
Adminクラスで使用できるオプションはこちらです。
ここに書かれていること以外のカスタマイズは、Adminクラスのメソッドをオーバーライドすることになります。
しかし一般サイト用のViewクラス群と比較すると、拡張することをあまり意識した作りにはなっていない部分も多いです。
かなりの行数がある一枚岩のメソッドや、モジュール内のプライベート関数を呼び出している部分も存在し、オーバーライドはかなり難しいケースもあったりします。
最後に
色々書きましたが、管理サイトは管理者向けのツールとしては非常に強力なツールです。使わない理由はありません。
管理ツールを使うメリットとしては
- 一般サイトがなくてもデータを登録・閲覧できる
- 一般サイトでは表示しない項目を表示できる
- 生データに近い状態でデータを閲覧できる
などもあります。
管理ツールの用途・制限を理解した上で、用法用量を守って正しくお使い下さい。