Werkzeugチュートリアル—Werkzeugドキュメント
Werkzeugチュートリアル
Werkzeugチュートリアルへようこそ。このチュートリアルでは、URLをredisインスタンスに格納する TinyURL クローンを作成します。 このアプリケーションに使用するライブラリは、テンプレート用の Jinja 2、データベースレイヤー用の redis 、そしてもちろん、WSGIレイヤー用のWerkzeugです。
pip を使用して、必要なライブラリをインストールできます。
また、ローカルマシンでredisサーバーが実行されていることを確認してください。 OS Xを使用している場合は、 brew を使用してインストールできます。
UbuntuまたはDebianを使用している場合は、apt-getを使用できます。
RedisはUNIXシステム用に開発されたものであり、Windowsで動作するように実際に設計されたことはありません。 ただし、開発目的では、非公式のポートで十分に機能します。 github から入手できます。
まもなくご紹介
このチュートリアルでは、Werkzeugを使用して簡単なURL短縮サービスを一緒に作成します。 Werkzeugはフレームワークではなく、独自のフレームワークまたはアプリケーションを作成するためのユーティリティを備えたライブラリであるため、非常に柔軟性があることに注意してください。 ここで使用するアプローチは、使用できる多くのアプローチの1つにすぎません。
データストアとして、ここではリレーショナルデータベースの代わりに redis を使用して、これを単純に保ちます。これは、 redis が得意とする種類の仕事だからです。
最終結果は次のようになります。
ステップ0:基本的なWSGIの概要
Werkzeugは、WSGI用のユーティリティライブラリです。 WSGI自体は、WebアプリケーションがWebサーバーと通信できること、さらに重要なことにWebアプリケーションが適切に連携することを保証するプロトコルまたは規則です。
Werkzeugの助けを借りないWSGIの基本的な「HelloWorld」アプリケーションは次のようになります。
WSGIアプリケーションは、environdictとstart_response
呼び出し可能オブジェクトを呼び出して渡すことができるものです。 環境にはすべての着信情報が含まれています。start_response
関数を使用して、応答の開始を示すことができます。 Werkzeugを使用すると、要求オブジェクトと応答オブジェクトが提供されているため、直接処理する必要はありません。
リクエストデータはenvironオブジェクトを受け取り、その環境からのデータに適切な方法でアクセスできるようにします。 応答オブジェクトはそれ自体がWSGIアプリケーションであり、応答を作成するためのはるかに優れた方法を提供します。
応答オブジェクトを使用してそのアプリケーションを作成する方法は次のとおりです。
そして、ここでは、URL内のクエリ文字列を調べる拡張バージョンです(さらに重要なのは、URL内の name パラメーターを調べて、別の単語を「World」に置き換えます)。
WSGIについて知っておく必要があるのはこれだけです。
ステップ1:フォルダーの作成
始める前に、このアプリケーションに必要なフォルダーを作成しましょう。
shortlyフォルダーはPythonパッケージではなく、ファイルをドロップする場所です。 このフォルダに直接、メインモジュールを次の手順で配置します。 静的フォルダー内のファイルは、HTTP経由でアプリケーションのユーザーが利用できます。 これはCSSとJavaScriptファイルが行く場所です。 テンプレートフォルダ内で、Jinja2にテンプレートを検索させます。 チュートリアルの後半で作成するテンプレートは、このディレクトリに配置されます。
ステップ2:基本構造
それでは、それを理解して、アプリケーション用のモジュールを作成しましょう。 shortly フォルダに shortly.py というファイルを作成しましょう。 最初はたくさんの輸入品が必要になります。 混乱しないように、すぐに使用されなくても、ここにすべてのインポートを取り込みます。
次に、アプリケーションの基本構造とその新しいインスタンスを作成する関数を作成できます。オプションで、Web上の static フォルダーにあるすべてのファイルをエクスポートするWSGIミドルウェアを使用します。
最後に、自動コードリロードとデバッガーを使用してローカル開発サーバーを起動するコードを追加できます。
ここでの基本的な考え方は、Shortly
クラスが実際のWSGIアプリケーションであるということです。 __call__
メソッドは、wsgi_app
に直接ディスパッチします。 これは、[X83X] をラップして、create_app
関数の場合と同じようにミドルウェアを適用できるようにするためです。 次に、実際のwsgi_app
メソッドはRequest
オブジェクトを作成し、dispatch_request
メソッドを呼び出します。このメソッドは、Response
オブジェクトを返す必要があり、WSGIアプリケーションとして再度評価されます。 。 ご覧のとおり、カメはずっと下にいます。 作成したShortly
クラスと、Werkzeugのリクエストオブジェクトの両方がWSGIインターフェイスを実装しています。 その結果、dispatch_request
メソッドから別のWSGIアプリケーションを返すこともできます。
create_app
ファクトリ関数を使用して、アプリケーションの新しいインスタンスを作成できます。 一部のパラメーターを構成としてアプリケーションに渡すだけでなく、オプションで静的ファイルをエクスポートするWSGIミドルウェアを追加します。 このようにして、サーバーを構成してファイルを提供していない場合でも、静的フォルダーからファイルにアクセスできます。これは、開発に非常に役立ちます。
Intermezzo:アプリケーションの実行
これで、 python を使用してファイルを実行し、ローカルマシン上のサーバーを確認できるようになります。
また、リローダーがアクティブであることも通知します。 さまざまな手法を使用して、ディスク上のファイルが変更されたかどうかを判断し、自動的に再起動します。
URLにアクセスすると、「HelloWorld!」が表示されます。
ステップ3:環境
基本的なアプリケーションクラスができたので、コンストラクターに何か便利なことをさせて、便利なヘルパーをいくつか提供することができます。 テンプレートをレンダリングしてredisに接続できるようにする必要があるので、クラスを少し拡張してみましょう。
ステップ4:ルーティング
次はルーティングです。 ルーティングは、URLを使用可能なものと照合して解析するプロセスです。 Werkzeugは、そのために使用できる柔軟な統合ルーティングシステムを提供します。 それが機能する方法は、Map
インスタンスを作成し、Rule
オブジェクトの束を追加することです。 各ルールには、URLを照合しようとするパターンと「エンドポイント」があります。 エンドポイントは通常文字列であり、URLを一意に識別するために使用できます。 これを使用してURLを自動的に逆にすることもできますが、このチュートリアルではそれを行いません。
これをコンストラクターに入れるだけです:
ここでは、3つのルールを使用してURLマップを作成します。 /
は、新しいURLを作成するロジックを実装する関数にディスパッチするURLスペースのルートです。 次に、ターゲットURLへの短いリンクをたどるリンクと、同じルールで最後にプラス(+
)を付けてリンクの詳細を表示するリンクを示します。
では、エンドポイントから関数への道をどのように見つけるのでしょうか? それはあなた次第です。 このチュートリアルで行う方法は、クラス自体のメソッドon_
+エンドポイントを呼び出すことです。 これがどのように機能するかです:
URLマップを現在の環境にバインドし、URLAdapter
を取得します。 アダプターを使用して、要求を照合するだけでなく、URLを逆にすることもできます。 matchメソッドは、エンドポイントとURLの値のディクショナリを返します。 たとえば、follow_short_link
のルールには、short_id
という可変部分があります。 http://localhost:5000/foo
に移動すると、次の値が返されます。
何にも一致しない場合は、NotFound
例外が発生します。これはHTTPException
です。 すべてのHTTP例外は、それ自体がデフォルトのエラーページを表示するWSGIアプリケーションでもあります。 したがって、それらすべてをキャッチして、エラー自体を返します。
すべてが正常に機能する場合は、関数on_
+エンドポイントを呼び出し、リクエストを引数として渡し、すべてのURL引数をキーワード引数として渡し、メソッドが返す応答オブジェクトを返します。
ステップ5:最初のビュー
最初のビューから始めましょう:新しいURLのビュー:
このロジックは理解しやすいはずです。 基本的に、リクエストメソッドがPOSTであることを確認しています。この場合、URLを検証し、データベースに新しいエントリを追加してから、詳細ページにリダイレクトします。 これは、関数とヘルパーメソッドを作成する必要があることを意味します。 URL検証の場合、これで十分です。
URLを挿入するために必要なのは、クラスの次の小さなメソッドだけです。
reverse-url:
+ URLは短いIDを保存します。 URLがすでに送信されている場合、これはNoneにはならず、短いIDとなるその値を返すことができます。 それ以外の場合は、last-url-id
キーをインクリメントし、base36に変換します。 次に、リンクとリバースエントリをredisに保存します。 そしてここでベース36に変換する関数:
したがって、このビューが機能するために欠けているのはテンプレートです。 これは後で作成します。最初に他のビューも作成してから、テンプレートを一度に作成します。
ステップ6:ビューをリダイレクトする
リダイレクトビューは簡単です。 それがしなければならないのは、redisでリンクを探してそれにリダイレクトすることだけです。 さらに、リンクがクリックされた頻度がわかるように、カウンターもインクリメントします。
この場合、URLが存在しない場合、手動でNotFound
例外を発生させます。これにより、dispatch_request
関数にバブルアップし、デフォルトの404応答に変換されます。
ステップ7:詳細ビュー
リンクの詳細ビューは非常によく似ています。テンプレートを再度レンダリングするだけです。 ターゲットを検索することに加えて、リンクがクリックされた回数をredisに要求し、そのようなキーがまだ存在しない場合はデフォルトでゼロにします。
redisは常に文字列で機能するため、クリック数をint
に手動で変換する必要があることに注意してください。
ステップ8:テンプレート
そして、ここにすべてのテンプレートがあります。 それらを templates フォルダーにドロップするだけです。 Jinja2はテンプレートの継承をサポートしているため、最初に行うことは、プレースホルダーとして機能するブロックを使用してレイアウトテンプレートを作成することです。 また、Jinja2は、HTMLルールを使用して文字列を自動的にエスケープするように設定しているため、自分で時間を費やす必要はありません。 これにより、XSS攻撃とレンダリングエラーが防止されます。
layout.html :
new_url.html :
short_link_details.html :
ステップ9:スタイル
これが醜い白黒よりも見栄えがするために、ここに沿った簡単なスタイルシートがあります:
static / style.css :
ボーナス:改良
Werkzeugリポジトリのサンプル辞書の実装を見て、カスタム404ページなどのいくつかの小さな改良を加えたこのチュートリアルのバージョンを確認してください。