HTMLの分析を行う際、タグを巡回する必要がありますがそんなとき、lxmlを使うと便利です。

lxmlでは、タグの入れ子関係が壊れたHTMLの修復も自動で行ってくれる機能がありますのでユーザは細かいことを気にする必要はありません。この修復機能のおかげで、入れ子の修復（閉じ括弧がないタグは閉じ括弧を付与）を行ってくれるため、HTMLをツリーとして、つまりDOMツリーとして捉えることができるようになるのです。

DOMツリーだから何やねん！という方は読み飛ばしてもらっていいのですが、ツリーであるおかげで親ノード（親タグ）をたぐったり、兄弟ノード（兄弟タグ）をたぐったりが簡単にできるようになるのですね。lxmlってすばらしい。

木を巡回する手法はいろいろとありますが、今日は深さ優先で巡回する手法をみてみましょう。

lxmlを使えば、タグの除去も超簡単です！

tostring()もしくはXPathを使ってできるのですね〜。

lxmlは文字コードを厳格に定義しており、入力時は必ず「unicode」化しておく必要があります。

これだけでも注意しておかなければならない点ですが、lxmlには、出力用の「tostring()」というメソッドを持っており、ここでも文字コードの注意が必要となってきます。

PythonでXML/HTMLをパースする場合、

• DOMベースのBeautifulSoup

と

• SAXベースのlxml

の大きく２つが存在しています。

前者は以前このブログでも紹介していますので、ご覧下さい。DOMベースなので気軽にパース処理することができる反面、少々処理が重いです。

一方後者は、XPATHと呼ばれる問い合わせ言語（まぁ、SQLのようなもんです）をある程度理解する必要はありますが、メモリもそんなに使わず大変高速なため、phactoryではよく使っています。

今日はこのlxmlを使ってタグ抽出する方法を紹介します。

Djangoでは、save()を使ってレコードを作成したり更新したりすると思います。

オブジェクトが新規作成される場合はINSERT。そうでない場合はUPDATEとDjango側が自動的に切り分けてくれます。

これは、DBレイヤーでは、

• オブジェクトが持つ主キーがDB中に存在しない＝INSERT
• オブジェクトが持つ主キーがDB中に存在する＝UPDATE

ということをしてくれています。

でも、毎回必ずINSERTしたい場合はどうでしょう？

pythonでHTTP通信する場合、urllib, urllib2あたりを使うことが多いと思います。

手軽で簡単ではあるのですが、どちらもレスポンスコードを取得することができません。

• urllibについては、python2.6以上であれば、urlopen().getcode()メソッドでサポートされているが、それ以前のバージョンではサポートされていない。
• urllib2では、2xx系以外は例外が発生するためレスポンスコード取得できない。

「レスポンスコードをどうしても取得したい！」という場合は、httplibを使いましょう。

VirtualBoxを使って固定IPを設定してみましょう。

VirtualBox独自のDHCPサーバーを持っており、192.168.56.xxxのサブネットワークを形成しています。固定IP設定するには、まずこのDHCPサーバー機能を停止し、独自の固定IPを付与する必要があります。さらに、ホスト側のサブネットワークと通信できるように、例えばWinXPならブリッジネットワークにVirtualBoxのネットワークアダプタを追加して同じサブネットワーク内で通信できるようにする必要があります。

以下、ホストOSがWinXP、ゲストOSがDebian5の場合の設定方法です。

WYSIWYGエディタは、近年のWebのシステム化において非常に重要なウェイトを占めるようになってきています。

Djangoでも、いくつかWYSIWYGエディタをエンベットできるアプリが登場してきています。

今日は、これらアプリについて簡単な紹介をしたいと思います。

Djangoには、キャッシュバックエンドとして様々な機構をサポートしています。

1. メモリキャッシュ
2. データベースキャッシュ
3. ファイルキャッシュ

また、バックエンドとは別に、キャッシュ化できるデータの単位も様々です。

• サイト全体をキャッシュ化
• ビュー単位でキャッシュ化
• テンプレートの一部をキャッシュ化
• オブジェクトの単位でキャッシュ化

特に「オブジェクト単位」でキャッシュ化できるため、原理的には変数ひとつだけをキャッシュデータ化することも可能で、まさに究極の粒度をもったキャッシュ機能であると言えます。

また、もっと上流のキャッシュ機能とDjangoベースのWebサーバーを連携させることも可能です。例えば、squidなどのProxyベースのキャッシュ機能との連携がそれに該当します。

まさに、なんでもあり、のDjangoキャッシュ機能ですが、今回はその中でも最も高速なメモリベースのキャッシュを中心に、キャッシュの設定方法を見ていきましょう。

サイトマップを作成すると、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変数に、テンプレート変数を返すメソッドを登録しておくと、どのビューからでも当該変数をコンテキストに追加することが可能となります。

    $ emacs settings.py
      TEMPLATE_CONTEXT_PROCESSORS = (
         "hogeapp.context_processors.user_name",
         ...,
      )

    $ emacs hogeapp/context_processors.py
      def user_name(request):
         if ( request.user.is_authenticated() ):
            return {"uname": request.user.username}
         else:
            return {"uname": None}

上記の例は、ログインしている場合に、アカウント名を常に「uname」というテンプレート変数に格納するような設定です。

Djangoでモデル定義から直接フォームクラスを自動生成する方法については、ModelFormクラスを用いればよいと解説してきました。

しかし、モデルではフィールド定義してるけど、フォームを表示する際は表示する必要のないものや、ヘルプメッセージをどうやって表示すればよいのか？など、使うときに迷うこともあります。

今回は、このような細やかな要求をどうやって実現するのかについて、ノウハウメモ的に解説していきます。

HTMLを記述する場合に、

    <div class="odd"></div>
    <div class="even"></div>
    <div class="odd"></div>
    <div class="even"></div>
    ...

などと、クラス名を交互に切り替えたい場合があります。

このような場合、Djangoならばテンプレートフィルタの「cycle」を使って簡単に実現できます。

SSL通信（https）は、現代のWebサーバーには不可欠な技術です。

特に、個人情報を扱ったり決済機能を扱ったりするようなサービスを開発する場合はなおさらです。

そんなとき、SSL通信を使いますよね。
証明書は、第三者発行機関から入手する必要がありますが、有料のところがほとんどです。趣味の範囲で楽しむ程度なら、購入せず、「 自己証明書 」というものを使うので十分です。

これなら、どこにも依頼せず、無料でhttps通信を実現できます。

Djangoは、クラス定義（モデル）とデータベーステーブルとを関連付けるORM（Object-Relation Model）というフレームワークを採用しています。そのため、SQLやRDBのことが分からなくても、Python & Djangoの知識だけである程度データベースを利用することができます。

データベースとしては、PostgreSQL / MYSQL / Sqlite などが利用可能ですが、これらすべてが既存のテーブルに対して、カラムの追加・変更・削除処理をサポートしている訳ではありません。例えば、PostgreSQLはカラムの追加はできますが、変更（型や名前の変更など）はできません。

これらは、サポートしているデータベースが提供しているサービスで、共通部分のみしか使わないというDjangoの思想に基づいています。なので、モデル定義の変更・削除も同様に、

    $ python manage.py syncdb

では対応できないのです。

これを解決するためのDjangoアプリケーションがあります。
「django-evolution」です。
これを使えば、モデルの変更・削除が実現できます。

Snow LeopardにMacOSXをアップグレードすると64bit対応のあおりで、portのパッケージ群が動作しなくなってしまいます。これを対応させるためには、環境を手作業で一つ一つ修正していくよりも、思い切って全パッケージを削除して一からアプリケーションを全インストールする方が楽に移行できます。

今回は、Pinaxのインストール方法について説明します。Pinaxのインストールは前バージョンである0.5.1から大きく様変わりしています。前回までは、Pinax自体のパッケージをPythonパスの通ったところに配置するだけでよかったのですが、今回はインストーラが附属していたり、Pinaxが動作するために必要な外部パッケージ（Djangoなど）も同時にインストールされるようになっています。

Pinaxは、Djangoフレームワークで実装されたアプリケーション集です。

デフォルトのテンプレートも最初から提供されているため素早くサイトを立ち上げることが可能です。

用途に応じて、個人のブログサイトやコーポレートサイト、エンタープライズ用途のCMSに至るまで様々なデフォルトプロジェクトも予め用意されており、30〜40個のアプリのどれをインストールして使えばよいか悩むこともありません。

今回は、Pinaxの全容を紹介します。