サイトマップを作成すると、Google, Bingなどの検索エンジンに効率的にクローリングしてもらえるようになるだけでなく、ホスティングしているページ全体に対して、何割がインデックスされているのか?検索エンジンの進捗を確認することが可能となり、SEO効果が期待できます。 しかし、サイトマップ一つとっても、そのフォーマットを覚えたり、XMLを整形したりするために多分の労力を払う必要があり、容易ではありません。 しかし、Djangoにはサイトマップを簡単に作成する機能が組み込まれています。 この機能を提供するのが、 django.contrib.sitemap クラスです。 開発者は、モデルに対するサイトマップクラスを定義するだけで、サイトマップ用のビューを生成することが可能です。 簡単なアプリを例にとり、サイトマップの作成方法を見ていきましょう。
Djangoでは、アプリ、context_processorsなど様々なプラグイン機能が提供されており、画一的なフレームワークの中でソフトウェアを実装することで効率化・高可搬性を実現しています。 しかし、一旦システムを実装開始すると、システムは様々な環境が依存しあうもので、一つの関数を書き換えると様々なビューやテンプレートファイルに修正範囲が波及する。。。なんてことがよく起こります。
せっかくMVCフレームワークを提供しているのに、それを正しく使わないのが悪い!などと怒られそうですが、理想と現実は異なる訳で、プラットフォームにはそのどちらもフォローできる柔軟な環境が求められます。
既存のシステム全てに共通で処理をフックしたり、テンプレート変数を追加したい。。。などということを実現するにはどうしたら良いのでしょうか? これを簡単に実現できる方法がDjangoにはあります。 それが「ミドルウェア」です。
Djangoでは、ビュー関数名やビューに付けた名前(=名前付きURLパターン)から対応するURLを逆引きする機能をサポートしています。 これを URLの逆引き と呼びますが、この機能を使うとHTML上でURLを直接記述する必要がなくなり、アプリケーションの可搬性が高まります。つまり、通常URL設計を変更する場合、テンプレートやビュー内で変更対象となる部分を書き換える必要が出てきますが、このような書き換え作業から開放されるのです。 それでは、URLの逆引き方法を見てみましょう。
Djangoには、テンプレートファイル内でのみ利用できるテンプレート変数と、グローバル変数のように、どのテンプレートファイルからも利用できるテンプレート変数も存在しています。 そのようなグローバル変数的なテンプレート変数のことをcontext_processorと呼びます。
settings.pyにて、TEMPLATE_CONTEXT_PROCESSORS変数に、テンプレート変数を返すメソッドを登録しておくと、どのビューからでも当該変数をコンテキストに追加することが可能となります。
HTMLを記述する場合に、
<div class="odd"></div>
<div class="even"></div>
<div class="odd"></div>
<div class="even"></div>
...
などと、クラス名を交互に切り替えたい場合があります。 このような場合、Djangoならばテンプレートフィルタの「cycle」を使って簡単に実現できます。
データベースとしては、PostgreSQL / MYSQL / Sqlite などが利用可能ですが、これらすべてが既存のテーブルに対して、カラムの追加・変更・削除処理をサポートしている訳ではありません。例えば、PostgreSQLはカラムの追加はできますが、変更(型や名前の変更など)はできません。
これらは、サポートしているデータベースが提供しているサービスで、共通部分のみしか使わないというDjangoの思想に基づいています。なので、モデル定義の変更・削除も同様に、
$ python manage.py syncdb
では対応できないのです。 これを解決するためのDjangoアプリケーションがあります。
「django-evolution」です。 これを使えば、モデルの変更・削除が実現できます。
今回は、Pinaxのインストール方法について説明します。Pinaxのインストールは前バージョンである0.5.1から大きく様変わりしています。前回までは、Pinax自体のパッケージをPythonパスの通ったところに配置するだけでよかったのですが、今回はインストーラが附属していたり、Pinaxが動作するために必要な外部パッケージ(Djangoなど)も同時にインストールされるようになっています。