「どのように Waves は Resource 指向か?」の編集履歴(バックアップ)一覧はこちら

どのように Waves は Resource 指向か?」(2008/12/25 (木) 04:31:11) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

http://www.rubywaves.com/resource-oriented resource-oriented Waves: MVC を超えた HTTP HTTP では、メソッドは「リソースに実行されるべき方法」として定義されています。 Waves は文字通り実行します。 class Dog < Waves::Resources::Base def get "Ruff!" if request.path == '/bark' end end リクエスト DSL Waves では HTTP に基づいたリソースのメソッド呼び出しを行います。もちろん それだけなら何の役にも立たないでしょう。 しかし Waves は「要求にあった良いDSL」(request-dsl)も提供します。 Rails では「routes」と呼ばれています。 Waves ではもう少し洗礼されていて、単にリソースにメソッドを定義しているだけです。 class Dog include Waves::Resources::Mixin on( :get, [ 'bark' ] ) { "Ruff!" } end このリクエストDSLにはたくさんの特徴があります。経路コンポーネントを得るのを許し、規定値を設定し、正規表現やラムダに適合しているか、いろいろなコンポーネントに対してワイルドカードマッチングを行い、pathsと名づけられた経路生成メソッドを定義します。...など。 class Dog include Waves::Resources::Mixin on( :get, [ 'name' ] ) { "Fido" } on( :get, [ 'breed' ] ) { "Mutt" } end (忘れないでください。これらは最後に入って最初に依頼されたものにマッチするでしょう。まさしくそうした再定義の方法を得ています。実際にあなたがしているように) Functors 要求 与えられたリソースを得るためのいくつかのGETメソッドを持っているとどうなるでしょうか? 要求 DSL は実際に要求 functors を生成します。これらは本質的にはオーバーロードされたメソッドです(通称マルチメソッドディスパッチ)。こららは functor gem を使うためにおなじみのGEMを使います。 Resource Delegation もうひとつの非常に重要な特徴は resource delegation の概念です。アプリケーション自体がリソースのグループのプロキシとして本質的に動作するという考えがここにあります。アプリケーションリソースは単にリクエストがどこへ移譲されるかを点検しています。 class Animal include Waves::Resources::Mixin on( true, [ :animal, true ] ) { to( captured.animal ) } end この簡単な規則がすることはフォーム /dog/... や /cat/... の要求を対応付け、適切な動物リソースに送ることです。こうするといくつかの本当に良い利点があります。 こうすることでモノを管理しやくす保ちます。ルートベースアプローチでかなり多くのルートで終わることが出来ます。(?)要求ファンクタにより他のいろいろなメソッドが実行されるように別々のクラスで壊れてしまいます。(?) 以下にいくつかの性能上の利点を示します。たくさんのリソース/メソッドのあるアプリケーションには、はるかに少ない要求パターンで対応します。mixinや継承を使えるRubyを最大限に利用でき、その他あなたのアプリケーションで使用する共通のパターンを加えるためのDSLを拡張することさえ可能です。
http://www.rubywaves.com/resource-oriented resource-oriented Waves: MVC を超えた HTTP HTTP では、メソッドは「リソースに実行されるべき方法」として定義されています。 Waves は文字通り実行します。 class Dog < Waves::Resources::Base def get "Ruff!" if request.path == '/bark' end end リクエスト DSL Waves では HTTP に基づいたリソースのメソッド呼び出しを行います。もちろん それだけなら何の役にも立たないでしょう。 しかし Waves は「要求にあった良いDSL」(request-dsl)も提供します。 Rails では「routes」と呼ばれています。 Waves ではもう少し洗礼されていて、単にリソースにメソッドを定義しているだけです。 class Dog include Waves::Resources::Mixin on( :get, [ 'bark' ] ) { "Ruff!" } end このリクエストDSLにはたくさんの特徴があります。経路コンポーネントを得るのを許し、規定値を設定し、正規表現やラムダに適合しているか、いろいろなコンポーネントに対してワイルドカードマッチングを行い、pathsと名づけられた経路生成メソッドを定義します。...など。 class Dog include Waves::Resources::Mixin on( :get, [ 'name' ] ) { "Fido" } on( :get, [ 'breed' ] ) { "Mutt" } end (忘れないでください。これらはFirst-in Last-outにマッチするでしょう。そうした再定義の方法を選んでいます。実際にあなたがしているように) Functors 要求 与えられたリソースを得るためのいくつかのGETメソッドを持っているとどうなるでしょうか? 要求 DSL は実際に要求 functors を生成します。これらは本質的にはオーバーロードされたメソッドです(通称マルチメソッドディスパッチ)。こららは functor gem を使うためにおなじみのGEMを使います。 Resource Delegation もうひとつの非常に重要な特徴は resource delegation の概念です。アプリケーション自体がリソースのグループのプロキシとして本質的に動作するという考えがここにあります。アプリケーションリソースは単にリクエストがどこへ移譲されるかを点検しています。 class Animal include Waves::Resources::Mixin on( true, [ :animal, true ] ) { to( captured.animal ) } end この簡単な規則がすることはフォーム /dog/... や /cat/... の要求を対応付け、適切な動物リソースに送ることです。こうするといくつかの本当に良い利点があります。 こうすることでモノを管理しやくす保ちます。ルートベースアプローチでかなり多くのルートで終わることが出来ます。(?)要求ファンクタにより他のいろいろなメソッドが実行されるように別々のクラスで壊れてしまいます。(?) 以下にいくつかの性能上の利点を示します。たくさんのリソース/メソッドのあるアプリケーションには、はるかに少ない要求パターンで対応します。mixinや継承を使えるRubyを最大限に利用でき、その他あなたのアプリケーションで使用する共通のパターンを加えるためのDSLを拡張することさえ可能です。

表示オプション

横に並べて表示:
変化行の前後のみ表示:
記事メニュー
目安箱バナー