Django の admin をカスタマイズする

強力な admin アプリケーションを要求に合わせてカスタマイズするための 3 つの方法

Django に提供されている組み込みの管理コンソールは Django の最大のセールスポイントの 1 つです。しかし単にルック・アンド・フィールをカスタマイズするだけでなく、いくつかのモデル・フィールドをカスタマイズしたい場合にはどうすればよいのでしょう。ソースを変更せずに既存の admin アプリケーションを拡張する方法を学びましょう。

Liza Daly, Software Engineer and Owner, Threepress Consulting Inc.

Photo of Liza DalyLiza Daly は、出版業界向けアプリケーションを専門とするソフトウェア・エンジニアです。Oxford University Press、O'Reilly Media やその他の出版社の主要なオンライン製品の開発リーダーを務めてきました。現在、コンサルタントとして独立している彼女は、電子ブック・アプリケーションの開発を目的とするオープンソース・プロジェクト、Threepress の創始者でもあります。



2009年 5月 26日

Django admin

Django には、成熟した標準ライブラリー、活発なユーザー・コミュニティー、そして Python 言語を使用することによるあらゆるメリット、といった多くの特徴があります。他の Web フレームワークにも同様の特徴があるかもしれませんが、Django に特有のものとして、Django に組み込まれている管理アプリケーション admin があります。

admin には、高度な CRUD (Create-Read-Update-Delete) 機能が最初から用意されているため、何時間もかけてこの毎度おなじみの機能を用意する必要がありません。このことは大抵の Web アプリケーション開発にとって重要なポイントになります。つまり開発中には、プログラマーは彼らのデータベース・モデルを素早く検証することができ、またデプロイメントの際には、技術者ではないエンドユーザーが admin を使ってサイトのコンテンツを追加したり編集したりすることができます。

admin を実際に使う場合には、必ず何らかのカスタマイズが行われます。Django のドキュメントには、admin の基本的なルック・アンド・フィールを変更するためのガイドラインが大量に用意されており、また Django 自体にも admin の動作のサブセットを変更するための簡単な方法がいくつか含まれています。しかし、それ以上のことをしたい場合にはどうすればよいのでしょう。どこから始めればよいのでしょう。この記事では、admin を高度にカスタマイズするためのガイドラインを提供します。

admin の簡単な紹介

ほとんどの Django 開発者は admin のデフォルト機能をよく理解しています。簡単な復習として、最上位レベルの urls.py を編集して admin を有効にすることから始めましょう (リスト 1)。

リスト 1. urls.py で admin を有効にする
from django.conf.urls.defaults import *

# Uncomment the next two lines to enable the admin:
from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('',
    # Uncomment the next line to enable the admin:
    (r'^admin/(.*)', admin.site.root),
)

この記事で使用するソフトウェアのバージョン

  • Django V1.0.2
  • SQLite V3
  • Python V2.4-2.6 (Django はまだ Python V3 をサポートしていません)
  • IPython (サンプル出力用)

Django の ORM (Object-Relational Mapper) は多くのデータベース・バックエンドをサポートしていますが、SQLite はインストールが最も容易であり、また多くのオペレーティング・システムに付属しています。ここで紹介する例はどのバックエンドでも動作するはずです。Django でサポートされているデータベースの一覧は「参考文献」を参照してください。

Django には、スタンドアロンのコードで作業環境をセットアップできる手軽なショートカットが用意されています。つまり python manage.py shell を実行すれば作業環境をセットアップすることができます。この記事で紹介するすべてのコード・サンプルは、この方法で環境が呼び出されていることを前提にしています。Django の用語を使って表現すると、この記事では以下を前提としています。

  • これは more_with_admin という名前の Django プロジェクトです。
  • more_with_admin プロジェクトには examples というアプリケーションが含まれています。

この examples アプリケーションは、基本的なブログ風の文書システムと、それらの文書に対するコメント (コメントが無い場合もあります) をモデリングしています。コマンドラインの例はすべて、プロジェクトのルート、つまりメインの more_with_admin ディレクトリーから行ったものです。

admin を有効にするには、さらに django.contrib.admin アプリケーションを settings.INSTALLED_APPS に追加する必要があります。

admin を大幅に拡張しようと思っている場合には、この先を読み進める前に admin のソース・コードを十分理解しておくことをお勧めします。ショートカットやシンボリック・リンクをサポートするオペレーティング・システムの場合には、admin アプリケーションへのショートカットやシンボリック・リンクを作成しておくと便利です。

admin は Django パッケージの中にあります。setuptools を使ってインストールした場合には、admin は django/contrib/admin 配下の site-packages の中にあります。以下に示すのが、あるプロジェクトから Django admin のソースへのシンボリック・リンクの一例です。使用しているオペレーティング・システムと Django がインストールされている場所に応じてこのシンボリック・リンクをカスタマイズすると、コピーや参照を容易に行えるようになります。

$ ln -s /path/to/Python/install/site-packages/django/contrib/admin admin-source

admin.autodiscover() メソッドは settings.INSTALLED_APPS の中にある各アプリケーションに対して繰り返し処理を行い、admin.py というファイルを探します。admin.py は通常、アプリケーション・ディレクトリーの最上位レベルの、models.pyと同じレベルに置かれています。

examples アプリケーションには、リスト 2 に示す models.py が必要です。これに対応する admin.py を以下に示します。

リスト 2. このアプリケーションの models.py の例
from django.db import models

class Document(models.Model):
    '''A Document is a blog post or wiki entry with some text content'''
    name = models.CharField(max_length=255)
    text = models.TextField()
    
    def __unicode__(self):
        return self.name

class Comment(models.Model):
    '''A Comment is some text about a given Document'''
    document = models.ForeignKey(Document, related_name='comments')
    text = models.TextField()

ここで、次のように Django 開発サーバーを実行すると admin を呼び出すことができます。

python manage.py runserver

admin は、デフォルトの場所である http://localhost:8000/admin/ にあります。ログインすると、基本的な admin 画面が表示されます (図 1)。

図 1. Django の基本的な admin 画面
Django の基本的な admin 画面

admin.py でのコードの変更

Django アプリケーションの他のファイルとは異なり、Django 開発用 Web サーバーを使って admin.py を変更する場合には、このサーバーを手動で再起動する必要があるかもしれません。

まだモデルが表示されていないことに注意してください。これは admin.py をまだ作成していないからです。リスト 3 は admin の中でモデルを扱うためのコードを示しています。

リスト 3. admin.py の例
from django.contrib import admin
from more_with_admin.examples import models

class DocumentAdmin(admin.ModelAdmin):
    pass

class CommentAdmin(admin.ModelAdmin):
    pass

admin.site.register(models.Document, DocumentAdmin)
admin.site.register(models.Comment, CommentAdmin)

ここで admin にメイン・ページをリロードすると、新しいモデルが利用できるようになっていることがわかります (図 2)。

図 2. Django admin でカスタム・モデルをサポートする準備が整った状態
Django admin でカスタム・モデルをサポートする準備が整った状態

admin の model ページをカスタマイズする

admin フォルダーのディレクトリー名

モデルの名前に小文字を使っていることに注意してください。これは通常の admin ページで URL を生成する場合の原則に従っています。Django では、こうした URL として使いやすい形式を「スラグ (slug)」と呼んでいます。対象のモデルに対する適切なスラグが不明な場合には、ディレクトリーを作成する前にまず admin を調べ、URL に現れる名前をメモしてください。

Django のソース・コードに手を加えずに admin をカスタマイズする方法を理解するには、admin が他のアプリケーションとまったく同じ通常の Django アプリケーションであることを念頭に置いておくことが重要です。これは何よりも、Django のテンプレート継承システムを適用できるということです。

Django はテンプレートを検索する場合、必ずユーザー独自のプロジェクトのテンプレートをシステムのテンプレートよりも優先させて検索をします。また admin は、デフォルトのテンプレートを使う前に、各モデルに対応するハードコーディングされたテンプレートを検索しようとします。こうした検索機能のおかげで容易にカスタマイズを行えるようになります。

まず、このプロジェクトの settings.py を編集し、自分で作成したテンプレートを格納するテンプレート・ディレクトリーを必ず Django が調べるようにします。

リスト 4. settings.py を編集し、自分で作成したテンプレートを格納するテンプレート・ディレクトリーを調べるようにする
TEMPLATE_DIRS = (
    "/path/to/project/more_with_admin/templates",
    "/path/to/project/more_with_admin/examples/templates",
)

次に、プロジェクトの中に以下のディレクトリーを作成します。

$ mkdir templates/admin/examples/document/
$ mkdir templates/admin/examples/comment/

Django admin の特別な動作によって、アプリケーションの名前 (この場合は examples) を持つディレクトリー、そしてモデルの名前 (documentcomment) が調べられ、それからシステムのテンプレートを使って管理ページが描画されます。

1 つのモデルの追加/編集用のページを変更する

モデル・インスタンスの追加と編集用に admin が使うページの名前は change_form.html です。まず、Document モデルのディレクトリーの中に templates/admin/examples/document/change_form.html というページを作成し、その中に Django のテンプレート継承用の行として、{% extends "admin/change_form.html" %} を追加します。

これでカスタマイズの準備ができました。少し時間をかけ、実際の admin/change_form.html の内容を理解してください。このページは複数のテンプレート・ブロックとしてある程度適切に構成されており、変更が可能ですが、少しカスタマイズしようとすると何ブロックもの大がかりなコピーが必要かもしれません。とはいえ、どのような場合にも好ましい方法は、ページ全体をコピーする代わりにブロック・ベースでテンプレートを変更する方法です。

追加/編集用のページに対して、どのようなカスタマイズが必要なのでしょう。例えば、システムの中の各 Document に対して、最新の 5 つのコメントのプレビューを表示したいとします。

まず、何らかのサンプル・コンテンツを作成します。

リスト 5. Django のシェルを使用して、いくつかのコメントを持つサンプルの Document を作成する
$ python manage.py shell
In [1]: from examples import models
In [2]: d = models.Document.objects.create(name='Test document', 
                                           text='This is a test document.')
In [3]: for c in range(0, 10):
   ...:     models.Comment.objects.create(text='Comment number %s' % c, document=d)

すると、admin のリスト・ページに 1 つの Document が表示されます。この Document を選択すると、デフォルトの追加/編集用のページが表示されます (図 3)。

図 3. Document が表示されたデフォルトの追加/編集用のページ
Document が表示されたデフォルトの追加/編集用のページ

この文書に関連するコメントがまったく表示されていないことに注意してください。関連するモデルを admin に表示するためには、強力な Inline クラスを使う方法が標準的です。Inline クラスを使うと、1 つのページ上で複数の関連モデルを追加、編集することができます。inlines の動作を調べるために、admin.py アプリケーションをリスト 6 のように編集します。

リスト 6. 関連モデルとしての Comment を Document admin に追加する
from django.contrib import admin
from more_with_admin.examples import models

class CommentInline(admin.TabularInline):
    model = models.Comment

class DocumentAdmin(admin.ModelAdmin):
    inlines = [CommentInline,]

class CommentAdmin(admin.ModelAdmin):
    pass

admin.site.register(models.Document, DocumentAdmin)
admin.site.register(models.Comment, CommentAdmin)

図 4 は TabularInline コントロールを追加した後の新しい追加/編集用のページを示しています。

図 4. Comment モデルが Inline として追加された後の Document の追加/編集用のページ
Comment モデルが Inline として追加された後の Document の追加/編集用のページ

これは確かに強力ですが、コメントのプレビューを素早く表示したいだけの場合は、少しやりすぎかもしれません。

プレビューを素早く表示するためには 2 つの方法が考えられます。1 つの方法は、inline に関連付けられている HTML ウィジェットを Django admin のウィジェット・インターフェースを使って編集する方法です (Django のドキュメントにはウィジェットの詳細が説明されています)。もう 1 つの方法は、追加/編集用ののテンプレートを直接変更する方法です。admin 特有の機能をまったく使用したくない場合には、この方法が最も有用です。

ユーザーにはコメントの編集ができないようにし (例えばユーザーが十分なアクセス権を持っていないなど)、ただしユーザーがコメントを見ることはできるようにしたい場合には、change_form.html を編集します。

ユーザーはコメントを見ることはできるけれども、コメントの編集はできないようにしたい (例えばユーザーが十分なアクセス権を持っていないなど) 場合には、change_form.html を編集します。

Django admin に用意されている変数

モデル・インスタンスのページに機能を追加するためには、どんなデータが admin にあるのかを知る必要があります。admin に用意されている 2 つの重要な変数を下記に挙げます。

表 1. admin のテンプレートをカスタマイズするために必要な変数
変数説明
object_idこれは編集対象のオブジェクトの主キーです。ある特定のインスタンスのページ (例えば Document など) をカスタマイズする場合には、必要な変数はこれだけです。
content_type_id複数のタイプのモデルのページを変更する場合には、この変数を使って ContentTypes フレームワークに対してクエリーを実行し、モデルの名前を取得します。ContentTypes については「参考文献」を参照してください。

admin ページに含めるためのテンプレート・タグを作成する

関連するコメントを一覧表示するには、そのためのコードが必要ですが、そのコードを Django のテンプレートに直接入力することはできません。このための最善のソリューションはテンプレート・タグを使う方法です。まず、テンプレート・タグのディレクトリーと __init__.py ファイルを作成します。

$ mkdir examples/templatetags/
$ touch examples/templatetags/__init__.py

新しいファイル examples/templatetags/example_tags.py を作成し、下記のコードを追加します。

リスト 7. 指定された Document ID に対するコメントを取得するテンプレート・タグ
from django import template
from examples import models

register = template.Library()

@register.inclusion_tag('comments.html')
def display_comments(document_id):
    document = models.Document.objects.get(id__exact=document_id)
    comments = models.Comment.objects.filter(document=document)[0:5]
    return { 'comments': comments }

このテンプレート・タグは inclusion タグなので、このタグに対応するテンプレート・ファイル (comments.html) を作成する必要があります。examples/templates/comments.html ファイルを編集し、リスト 8 のコードを入力します。

リスト 8. 一連のコメントのプレビューを表示するためのテンプレート
{% for comment in comments %}
<blockquote>{{ comment.text }}</blockquote>
{% endfor %}

今度はこのテンプレートを admin ページに追加します。admin.py の中にある CommentInline への参照をコメントアウトし、ローカル・バージョンの change_form.html にリスト 9 の変更を加えます。

リスト 9. 追加/編集用のページにテンプレート・タグを含める
{% extends "admin/change_form.html" %}

{% load example_tags %}

{% block after_field_sets %}
  {% if object_id %}{% display_comments object_id %}{% endif %}
  {% endblock %}

object_id を使う前に、object_id が存在するかどうかを調べることが重要です。change_form.html は新しいインスタンスを作成するためにも使われるからです (新しいインスタンスを作成する場合には、object_id はまだ存在していません)。after_field_sets ブロックは、admin に数多く用意されている拡張ポイントの 1 つにすぎません。他の拡張ポイントに関しては change_form.html のソース・ページを調べてください。

図 5 は更新されたフォームを示しています。

図 5. カスタムのテンプレート・タグを含めた後の Document の追加/編集用のページ
カスタムのテンプレート・タグを含めた後の Document の追加/編集用のページ

admin の動作を変更する

テンプレートを変更することで可能なことには限界があります。admin の実際のフローや動作を変更したい場合にはどうすればよいのでしょう。1 つの選択肢としてソースを変更する方法がありますが、この方法では、変更を行った特定のバージョンの Django に変更の効果が限定されてしまい、Django が更新された際には変更が適用されなくなってしまいます。

AdminModel メソッドを変更する

admin の中で Save をクリックすると、デフォルトでリスト・ページに戻ります。通常はこれで問題ありませんが、admin の外にあるオブジェクトのプレビュー・ページに直接ジャンプするにはどうすればよいのでしょう。これは CMS (コンテンツ管理システム) を開発する際によくあるケースです。

get_absolute_url() メソッドを提供する

リスト 10get_absolute_url() メソッドを含めるように Document が変更されていることを前提にしています。これは Django モデルがそのモデルの正準表現を指定するための推奨の方法です。正準表現が指定されている場合、Django admin はそのモデルの各ページに、便利な View on site ボタンも追加します。

admin アプリケーションのほとんどの機能は admin.ModelAdmin クラスに付随しています。admin.py の中で、オブジェクトはこのクラスから継承します。変更可能な public メソッドは非常にたくさんあります。このクラスの定義については admin-source/options.py のソースを調べてください。

Save ボタンの動作を変更する方法は 2 つあります。1 つは save の後のリダイレクト動作を実際に行う admin.ModelAdmin.response_add を変更する方法、もう 1 つは admin.ModelAdmin.change_view を変更する方法です。後者の方が少し簡単です。

リスト 10. save イベント後のリダイレクト先となるページを変更する
class DocumentAdmin(admin.ModelAdmin):

    def change_view(self, request, object_id, extra_context=None):

        result = super(DocumentAdmin, self).change_view(request, object_id, extra_context)

        document = models.Document.objects.get(id__exact=object_id)
        
        if not request.POST.has_key('_addanother') and 
              not request.POST.has_key('_continue'):
            result['Location'] = document.get_absolute_url()
        return result

このように変更した後、ユーザーが Save をクリックすると、すべての Document を表示するリスト・ページではなく、プレビュー・ページにリダイレクトされます。

シグナルを使って admin に機能を追加する

Django の機能の中でシグナルはあまり使われていませんが、シグナルはコードのモジュール性を高めてくれます。またシグナルによって、Django プロジェクトがリッスンしたり、応答したりすることが可能な任意の場所で機能するイベント (モデルの保存やテンプレートのロードなど) を定義することができます。これはつまり、アプリケーションを直接変更しなくてもアプリケーションの動作を容易に追加できるということです。

admin に用意された機能の中で、アプリケーション開発の際によく変更が必要となる機能が 1 つあります。それは django.contrib.auth.models.User クラスを使ってユーザーを管理する機能です。多くの場合、Django ユーザーの追加や変更を行える唯一の場所は admin であるため、この便利なクラスのカスタマイズは簡単ではありません。

例えば、新しい User オブジェクトが作成されるたびにサイト管理者が E メールを受信するようにしたいとします。User モデルをプロジェクトの中で直接使用することはできないため、そうした機能を実現するための方法は、User をサブクラス化するか、あるいは間接的な方法 (例えば変更用のダミーのプロファイル・オブジェクトを作成するなど) を使うしかないように思えるかもしれません。

リスト 11 を見ると、User インスタンスが保存されるときに実行される関数を追加することが、いかに容易であるかがわかります。こうした場合は通常、シグナルを models.py に追加します。

リスト 11. Django のシグナルを使って新しいユーザーの追加を通知する
from django.db import models
from django.db.models import signals
from django.contrib.auth.models import User
from django.core.mail import send_mail

class Document(models.Model):
    [...]

class Comment(models.Model):
    [...]

def notify_admin(sender, instance, created, **kwargs):
    '''Notify the administrator that a new user has been added.'''
    if created:
       subject = 'New user created'
       message = 'User %s was added' % instance.username
       from_addr = 'no-reply@example.com'
       recipient_list = ('admin@example.com',)
       send_mail(subject, message, from_addr, recipient_list)        

signals.post_save.connect(notify_admin, sender=User)

Django が提供している post_save シグナルは、モデルが保存あるいは作成されるたびに使用されます。ここで、connect() メソッドは 2 つの引数を取ります。つまりコールバック用の引数 (notify_admin) と、このコールバックが User モデルからの save イベントのみに関心があることを指定する sender 引数です。

このコールバックの中で、post_save シグナルが渡すのは、sender (モデル・クラス)、このモデルのインスタンス、そしてこのインスタンスがたった今作成されたものかどうかを示すブール値 (created) です。この例では、このメソッドは User が作成されていると E メールを送信し、それ以外の場合には何もしません。

post_save 以外に Django に用意されたシグナルの一覧と、独自のシグナルを作成する方法についての資料は、「参考文献」を参照してください。


さらに本格的な変更: 行レベルのパーミッションを追加する

なぜ blank=True なのか

ForeignKey フィールドがテキスト・フィールドではない場合、なぜ blank=True に設定されるのか、その理由は明白ではないかもしれません。この場合、その理由は、Django admin はモデルの保存前に手動で値を設定する必要があるかどうかを判断するために、null ではなく blank を使用するからです。

現行ユーザーが保存を実行する際のデフォルトの動作を、「added by」という値が選択された状態にしたい場合には、ForeignKey に null=True のみを指定するか、blank=True または null=True のいずれも指定しないようにします。すると、Django admin は保存前にこの動作をユーザーに強制するようになります。

よく Django admin に要求される機能として、権限管理システムを拡張して行レベルの権限を含めるようにしたい、という要求があります。admin ではデフォルトで、ロールや権限をきめ細かく制御することができますが、これらのロールを適用できるのはクラス・レベルのみです。そのためユーザーは、すべての Document を変更するか、あるいはどれも変更しない、という選択しかできません。

ユーザーは特定のオブジェクトしか変更できない、というようにしたい場合がよくあります。この機能は「行レベル」の権限と呼ばれることがよくあります。そう呼ばれる理由は、この機能で変更できるのはデータベース・テーブルの特定の行のみであり、テーブル内の任意のレコードを自由に変更できる包括的な権限ではないからです。examples アプリケーションでの使い方の例として、ユーザーが自分で作成した Document しか見られないようにするために、行レベルの権限を使うことができます。

まず、誰が Document を作成したかを記録する属性を含めるように models.py を更新します (リスト 12)。

リスト 12. 各 Document を作成したユーザーを記録するように models.py を更新する
from django.db import models
from django.db.models import signals
from django.contrib.auth.models import User
from django.core.mail import send_mail
    
class Document(models.Model):
    name = models.CharField(max_length=255)
    text = models.TextField()
    added_by = models.ForeignKey(User, 
      null=True, blank=True)

    def get_absolute_url(self):
        return 'http://example.com/preview/document/%d/' % self.id

    def __unicode__(self):
        return self.name
[...]

次に、どのユーザーが Document を作成したかを自動的に記録するコードを追加する必要があります。この場合にはシグナルは使えません。シグナルはユーザーのオブジェクトにアクセスできないからです。しかし ModelAdmin クラスにはリクエストを含むメソッドが用意されているため、このメソッドに現在のユーザーがパラメーターとして含まれています。

admin.py の中で save_model() メソッドを変更します (リスト 13)。

リスト 13. DocumentAdmin のメソッドを変更し、現在のユーザーが作成されると、そのユーザーをデータベースに保存する
from django.contrib import admin

class DocumentAdmin(admin.ModelAdmin):
    def save_model(self, request, obj, form, change):
        if getattr(obj, 'added_by', None) is None:
            obj.added_by = request.user
        obj.last_modified_by = request.user
        obj.save()

[...]

added_by の値が None の場合、それは新しいレコードであり、まだ保存されていないということです。(changefalse かどうかをチェックすることもできます。changefalse の場合はそのレコードを追加中であることを示しています。ただし added_by が空かどうかをチェックすると、そのチェックによって、admin の外部で追加されたレコードにも値が入ります。)

行レベルの権限を利用した、もう 1 つの機能として、Document のリストを制限し、ユーザーが自分で作成した Document しか表示されないようにする機能があります。ModelAdmin クラスには、このためのフックが queryset() というメソッドとして用意されています。このメソッドによって、任意のリスト・ページが返すデフォルトのクエリー・セットを決めることができます。

リスト 14 に示すように、queryset() を変更し、現在のユーザーが作成した Document のみにリストを制限します。スーパーユーザーはすべての Document を見ることができます。

リスト 14. リスト・ページが返すクエリー・セットを変更する
from django.contrib import admin
from more_with_admin.examples import models

class DocumentAdmin(admin.ModelAdmin):
   
    def queryset(self, request):
        qs = super(DocumentAdmin, self).queryset(request)

        # If super-user, show all comments
        if request.user.is_superuser:
            return qs
        
        return qs.filter(added_by=request.user)
[...]

これで、admin の Document リスト・ページに対するどのようなリクエストに対しても、現在のユーザーが作成した Document しか表示されなくなります (ただし現在のユーザーがスーパーユーザーの場合には、すべての Document が表示されます)。

もちろん現状では、ユーザーがその気になれば、アクセス権のない Document の ID を知り、その Document の編集ページにアクセスしてしまうことを防ぐことはできません。真にセキュアな行レベルの権限にするためには、さらにメソッドを変更する必要があります。しかし一般的に admin のユーザーはある程度信頼されているため、基本的な権限があればスムーズなワークフローを実現する上では十分な場合もあります。


まとめ

Django admin をカスタマイズするためには admin のソース・コードの知識が多少必要ですが、ハッカーのような知識はほとんど必要ありません。admin は、通常の Python の継承と Django 特有の機能 (シグナルなど) を使って拡張できるように構成されています。

まったく新しい管理インターフェースを作成することに比べ、admin をカスタマイズすることには以下を始めとする数多くのメリットがあります。

  • Django の開発が活発に続く限り、アプリケーションは Django が進化することによる恩恵を受けることができます。
  • admin は既に一般的な使い方の大部分をサポートしています。
  • プロジェクトに追加された外部アプリケーションを、独自に作成したコードと並べて自動的に管理することができます。

次にリリースされる Django V1.1 では、頻繁に要求される 2 つの新機能が admin に追加されます。1 つはリスト・ページ上でフィールドをインライン編集できる機能であり、もう 1 つは多数のオブジェクトを一度にまとめて更新できる「admin アクション」です。この 2 つの機能が追加されることによって、そうした一般的な機能をゼロの状態から作成する必要がなくなる一方、さらにカスタマイズするための拡張ポイントが追加されます。

参考文献

学ぶために

製品や技術を入手するために

  • 多くの Linux® ディストリビューションや Mac OS® X には SQLite が付属していますが、付属していない場合には SQLite プロジェクトのサイトからダウンロードすることができます。
  • V2.5 から、Python には SQLite のサポートがバンドルされており、他のドライバーは何も必要ありません。それ以前のバージョンの Python の場合には pysqlite を直接ダウンロードする必要があります。
  • 皆さんの次期オープンソース開発プロジェクトを IBM ソフトウェアの試用版を使って革新してください。ダウンロード、あるいは DVD で入手することができます。
  • IBM 製品の試用版をダウンロードするか、あるいはオンラインで IBM SOA Sandbox を試し、DB2®、Lotus®、Rational®、Tivoli®、WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品を試してみてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source, Web development
ArticleID=398865
ArticleTitle=Django の admin をカスタマイズする
publish-date=05262009