「rubywaves概要」の編集履歴（バックアップ）一覧はこちら

「rubywaves概要」(2008/04/27 (日) 19:46:13) の最新版変更点

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

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

== Waves 概要 ==
みんながするように Hello World から始めましょう。 Waves では、 mapping.rb ファイルに1行コードを書くだけで実現できます。 [fixme]するべきことすべてをどんなに簡単に行っているか考えてください。WavesはMVCフレームワークだけれど、時にMVCは過剰だとわかっています。[fixme]

 path '/' { 'Hello, World!' }


== リクエストラムダ ==
Waves のすべてはリクエストラムダから始まります。各マッピングはルールとブロックから成ります。 リクエストがルールにマッチしたときに、ブロックが実行されます。 ブロックには何でもおくことが出来ます。ルールには正規表現か任意のハッシュ値の制限のいずれかを含みます。正規表現にマッチするとブロックにパラメータが渡されます。 

=== Hello world, version 2: ===
 # /dan => Hello, Dan!
 path %r{^/(\w+)$} { |name| "Hello, #{name.capitalize}!" }


== Resource = Model + View + Controller ==
リクエストラムダは「リソース」（モデル・ビュー・コントローラの3層）の操作をサポートします。コントローラとビューを使うブロックへのマッピングルールを容易に記述する3つの特別なメソッドがあります。

use メソッドは、単にリソースコンテキストを設定するだけです。（例えば MVC クラスをインスタンス化する）
controller メソッドがコントローラのスコープで内で適切なコントローラをインスタンス化し、リクエストを初期化し、ブロック引数を評価します。
view メソッド は通常、コントローラブロックを評価した結果を引数とする場合を除いて同様に動作します。さらに、view メソッドは関連テンプレートから様々なインスタンス変数からアクセス可能な予約されたハッシュを持つかもしれません。

何かを表示する一般的な規則：
  path %r{^/#{resource}/#{name}/?$} do | model, name |
    use( resource ) | controller { find(name) } | 
      view { |object| show( resource => object ) }
  end


何かをREST-スタイルで更新する一般的な規則：
  path %r{^/#{resource}/#{name}/?$}, :method => :post do | model, name |
     use( resource ) | controller { update(name) } | 
       view { |object| show( resource => object ) }
   end
  end


== フィルタ ==
/admin で始まるどんな URL でも /login で password を要求する：
  before %r{^/admin/} do | model, name |
    redirect('/login') unless session[:user]
  end

隠蔽したりプライベートにし忘れたコントローラメソッドを追加してセキュリティホールを作ったかどうか心配する必要はありません。
アプリケーションによるリクエストマッピングのルールにより忘れられます。

== Mapping Mixins ==
mixin を使うと共通ルールのセットで要約できます。
例えば、Waves は「pretty URLs」にシンプルな CRUD コントローラをマッピングするルールセットを提供します。

必要なすべてを抽出したマッピングルールをマッピングファイルに含めることが出来ます：
  include Waves::Mapping::PrettyUrls::GetRules
  include Waves::Mapping::PrettyUrls::RestRules


== Just In Time Resources ==
Waves はそれとなくリソースを定義することを許しています (MVC triples). 与えられたタイプのリソースに使いたいイディオムを定義すると、/ が必要なときはWaves は急いで必要なクラスを定義するでしょう。これは開発の速度を上げ、文書化の量を減らし、テストすることを要求します。また再利用を推奨します。

この例では、データベースに存在するテーブルのEntry クラスを定義していませんが、プログラムで定義済みであるかのようにアクセス可能です：
  ~/blog $ waves_console
  irb(main):001:0> M = Blog::Models
  irb(main):002:0> M::Entry.all
  => []


== First Class Views ==
Waves では、 View はリクエストをテンプレートに反映させるクラスです。 それだけです。しかしながら、望むような独自の View クラスを定義することも出来ます。 異なったリソースに異なった View を割り当てることも可能です。あなた次第です。

テンプレートに helpers を使うことも出来ます。 Helpers は Views と Controllers と同様に魔法です。： 「賢い規定値」はさまざまな役立つメソッドまとまりとして提供され、特定のリソースに明確な helper を定義できます。

規定の helpers は、ネストされたビュー、レイアウト、markdown フォーマット、カスタム化されたフォームコントロールなどを含みます。

=== レイアウト ===
view にレイアウトを指定してください。

 layout :admin, :title => @entry.title do
  # markup for blog entry editor here
 end


もし、レイアウトをまたいで view を再利用したいなら、好みの再利用したい view メソッドを使って、re-factor するだけです。：

 layout :admin, :title => @entry.title do
  view :blog_entry, :editor_fragment, :entry => @entry
 end

入れ子になった view のためにアンダースコアを view の前に入れるような特別な規則は何もありません。あなたは望んだことを実行できるし、しなくてもよい。 どんな view も他の view と望むだけ何回でも入れ子にできます。

これは、いろいろなタイプのページ要素（フォーム、ダイアログ、メニュー、何でも）をレイアウト仕様にもてることを意味します。<fixme>全体のWebページは正当ではありません。フォームで使用したH2タグの代わりにH3タグを使いたいだけだとわかったとしても問題ありません。フォームレイアウトを変更するだけで出来ます。<fixme>

=== カスタムフォーム ===
Since Waves uses Markaby as its primary templating engine, there is no real need for form helpers just to create a text box or other form control. However, most real-world Web applications have a strong need to consistently render the label, control, help text, control groups, etc., as well as support more sophisticated composite controls, like date pickers. So Waves provides a property helper that uses templates that you can modify to render complete property blocks within a form. When you modify one of these templates, all your application forms will get the new control.

# use our custom date template to render a date picker
 property :type => :date, :name => reservation.start_date, 
  :value => @reservation.start_date, :class => :required


== セッション ==
You can store things in file-based session (database sessions coming soon), from pretty much anywhere you deal with a Resource (the request mappings, controller blocks, view templates, etc.):

 session[:user] = @user.id if User.authenticate( email,password)?


== 継承可能な設定 ==
You can define hierarchies of configurations for use in testing, development, and production scenarios because configurations are just Ruby classes and attributes are inherited. You can also incorporate your own attributes into the configuration just by declaring them using the attribute method or by defining a class method on a configuration.

 module Blog
  module Configurations
    class Development < Default
      host '127.0.0.1'
      port 3000
      reloadable [ Blog ]
      log :level => :debug  
      application do
        use Rack::ShowExceptions
        use Rack::Static, :urls => [ '/css', '/javascript' ], :root => 'public'
        run Waves::Dispatchers::Default.new
      end       
    end
  end
 end

== 設定可能なアプリケーション ==
You can customize the request processing chain using the application configuration parameter. Thus, you can define your development configuration to use the ShowErrors Rack “middleware” and set your production configuration to include an analytics module. You can even replace or extend the Waves dispatcher with your own!

Soon, we’ll add the ability to customize which Rack::Handler to use, like this:

server :mongrel

== 真のコード再読み込み ==
開発環境では、 誰もどんなコードの変更でもサーバを再起動させた状態にしておきたいものだ。 ほとんどのフレームワークはリクエストのたびにコードを再読み込みする。しかし、 以前に定義された定数がメモリに残っているとしばしばエラーをデバックするのを困難にします。Waves ではまずフレームワークで再読み込みの前に定義された古いクラスやモジュールを完全にアンロードし、 さらに、要求があるときだけ再読み込みをされます。だからパフォーマンスのペナルティを最小限に抑えられます。

== ホットパッチ ==
プロダクション環境では、あなたのコードに「ホットパッチ」を当てることが出来ます。, アプリケーションモジュールのコードを再読み込みしたときにだけ安全にコードを再読み込みします。LiveConsole と連携して、サーバを再起動しなくてもプロダクション環境にパッチをあてることが出来ます。 

== クラスタ ==
サーバクラスタを起動するのは簡単です。待ちうけポートを配列に設定して実行するだけです。：

  rake cluster:start
  To restart, just do:

  rake cluster:restart


== スレッドセーフ ==
いまやスレッドはクールではないとわかっています。しかし、Ruby 1.9 ではネイティブスレッドがサポートされるでしょう。 ほとんどの下品な Web アプリは　理想的なスレッドを作ります。 スレッドはメモリを共有します、これはリクエストを処理するときにたくさんのメモリを確保することを意味します。 そしてもしイベント駆動を使おうと決めても、リクエスト毎にスレッドを使うモデルがオプションであるとわかるとうれしくないですか？これが  Rack のようなスレッドセーフライブラリを使って、Waves がスレッドセーフに書かれているかの理由です。
 
== マイグレーション ==
Waves では Sequel によるマイグレーションをサポートし、使うのに必要な基本的な Rake タスクを定義しています。 マイグレーションは、複数ホスト間で安全なバージョンを提供する最も信頼できる方法で、 Waves はマイグレーションを簡単に使うよう補助しています。

== すべて Ruby ==
Waves はすべて Ruby で書かれています。またライブラリも Waves と同じアプローチを取っています。設定ファイルは Ruby です。リクエストマッピングのルールも Ruby だけです。 Markaby は Ruby のみで書かれています。 Sequel は SQL クエリを Ruby で書けます。 Rack アプリケーションは Ruby だけを使って書かれます。

Furthermore, none of these libraries, including Waves, are intrusive by nature. They add a smattering of extensions to the core Ruby library (mostly via the extensions gem), but they only extend, they don’t override (well, except for RubyGems). So you can use Ruby however you want without unexpected surprises.

Ruby はすべらしい言語です。, why should your framework get in its way? これは Waves とコンポーネントライブラリが採用した基本的なアプローチです。

== Waves 概要 ==
みんながするように Hello World から始めましょう。 Waves では、 mapping.rb ファイルに1行コードを書くだけで実現できます。 [fixme]するべきことすべてをどんなに簡単に行っているか考えてください。WavesはMVCフレームワークだけれど、時にMVCは過剰だとわかっています。[fixme]

 path '/' { 'Hello, World!' }


== リクエストラムダ ==
Waves のすべてはリクエストラムダから始まります。各マッピングはルールとブロックから成ります。 リクエストがルールにマッチしたときに、ブロックが実行されます。 ブロックには何でもおくことが出来ます。ルールには正規表現か任意のハッシュ値の制限のいずれかを含みます。正規表現にマッチするとブロックにパラメータが渡されます。 

=== Hello world, version 2: ===
 # /dan => Hello, Dan!
 path %r{^/(\w+)$} { |name| "Hello, #{name.capitalize}!" }


== Resource = Model + View + Controller ==
リクエストラムダは「リソース」（モデル・ビュー・コントローラの3層）の操作をサポートします。コントローラとビューを使うブロックへのマッピングルールを容易に記述する3つの特別なメソッドがあります。

use メソッドは、単にリソースコンテキストを設定するだけです。（例えば MVC クラスをインスタンス化する）
controller メソッドがコントローラのスコープで内で適切なコントローラをインスタンス化し、リクエストを初期化し、ブロック引数を評価します。
view メソッド は通常、コントローラブロックを評価した結果を引数とする場合を除いて同様に動作します。さらに、view メソッドは関連テンプレートから様々なインスタンス変数からアクセス可能な予約されたハッシュを持つかもしれません。

何かを表示する一般的な規則：
  path %r{^/#{resource}/#{name}/?$} do | model, name |
    use( resource ) | controller { find(name) } | 
      view { |object| show( resource => object ) }
  end


何かをREST-スタイルで更新する一般的な規則：
  path %r{^/#{resource}/#{name}/?$}, :method => :post do | model, name |
     use( resource ) | controller { update(name) } | 
       view { |object| show( resource => object ) }
   end
  end


== フィルタ ==
/admin で始まるどんな URL でも /login で password を要求する：
  before %r{^/admin/} do | model, name |
    redirect('/login') unless session[:user]
  end

隠蔽したりプライベートにし忘れたコントローラメソッドを追加してセキュリティホールを作ったかどうか心配する必要はありません。
アプリケーションによるリクエストマッピングのルールにより忘れられます。

== Mapping Mixins ==
mixin を使うと共通ルールのセットで要約できます。
例えば、Waves は「pretty URLs」にシンプルな CRUD コントローラをマッピングするルールセットを提供します。

必要なすべてを抽出したマッピングルールをマッピングファイルに含めることが出来ます：
  include Waves::Mapping::PrettyUrls::GetRules
  include Waves::Mapping::PrettyUrls::RestRules


== Just In Time Resources ==
Waves はそれとなくリソースを定義することを許しています (MVC triples). 与えられたタイプのリソースに使いたいイディオムを定義すると、/ が必要なときはWaves は急いで必要なクラスを定義するでしょう。これは開発の速度を上げ、文書化の量を減らし、テストすることを要求します。また再利用を推奨します。

この例では、データベースに存在するテーブルのEntry クラスを定義していませんが、プログラムで定義済みであるかのようにアクセス可能です：
  ~/blog $ waves_console
  irb(main):001:0> M = Blog::Models
  irb(main):002:0> M::Entry.all
  => []


== First Class Views ==
Waves では、 View はリクエストをテンプレートに反映させるクラスです。 それだけです。しかしながら、望むような独自の View クラスを定義することも出来ます。 異なったリソースに異なった View を割り当てることも可能です。あなた次第です。

テンプレートに helpers を使うことも出来ます。 Helpers は Views と Controllers と同様に魔法です。： 「賢い規定値」はさまざまな役立つメソッドまとまりとして提供され、特定のリソースに明確な helper を定義できます。

規定の helpers は、ネストされたビュー、レイアウト、markdown フォーマット、カスタム化されたフォームコントロールなどを含みます。

=== レイアウト ===
view にレイアウトを指定してください。

 layout :admin, :title => @entry.title do
  # markup for blog entry editor here
 end


もし、レイアウトをまたいで view を再利用したいなら、好みの再利用したい view メソッドを使って、re-factor するだけです。：

 layout :admin, :title => @entry.title do
  view :blog_entry, :editor_fragment, :entry => @entry
 end

入れ子になった view のためにアンダースコアを view の前に入れるような特別な規則は何もありません。あなたは望んだことを実行できるし、しなくてもよい。 どんな view も他の view と望むだけ何回でも入れ子にできます。

これは、いろいろなタイプのページ要素（フォーム、ダイアログ、メニュー、何でも）をレイアウト仕様にもてることを意味します。<fixme>全体のWebページは正当ではありません。フォームで使用したH2タグの代わりにH3タグを使いたいだけだとわかったとしても問題ありません。フォームレイアウトを変更するだけで出来ます。<fixme>

=== カスタムフォーム ===
Since Waves uses Markaby as its primary templating engine, there is no real need for form helpers just to create a text box or other form control. However, most real-world Web applications have a strong need to consistently render the label, control, help text, control groups, etc., as well as support more sophisticated composite controls, like date pickers. So Waves provides a property helper that uses templates that you can modify to render complete property blocks within a form. When you modify one of these templates, all your application forms will get the new control.

# use our custom date template to render a date picker
 property :type => :date, :name => reservation.start_date, 
  :value => @reservation.start_date, :class => :required


== セッション ==
ファイルベースのセッションをYou can store things in file-based session (database sessions coming soon), from pretty much anywhere you deal with a Resource (the request mappings, controller blocks, view templates, etc.):

 session[:user] = @user.id if User.authenticate( email,password)?


== 継承可能な設定 ==
You can define hierarchies of configurations for use in testing, development, and production scenarios because configurations are just Ruby classes and attributes are inherited. You can also incorporate your own attributes into the configuration just by declaring them using the attribute method or by defining a class method on a configuration.

 module Blog
  module Configurations
    class Development < Default
      host '127.0.0.1'
      port 3000
      reloadable [ Blog ]
      log :level => :debug  
      application do
        use Rack::ShowExceptions
        use Rack::Static, :urls => [ '/css', '/javascript' ], :root => 'public'
        run Waves::Dispatchers::Default.new
      end       
    end
  end
 end

== 設定可能なアプリケーション ==
You can customize the request processing chain using the application configuration parameter. Thus, you can define your development configuration to use the ShowErrors Rack “middleware” and set your production configuration to include an analytics module. You can even replace or extend the Waves dispatcher with your own!

Soon, we’ll add the ability to customize which Rack::Handler to use, like this:

server :mongrel

== 真のコード再読み込み ==
開発環境では、 誰もどんなコードの変更でもサーバを再起動させた状態にしておきたいものです。 ほとんどのフレームワークはリクエストのたびにコードを再読み込みします。しかし、 以前に定義された定数がメモリに残っているとしばしばエラーをデバックするのを困難にします。Waves ではまずフレームワークで再読み込みの前に定義された古いクラスやモジュールを完全にアンロードし、 さらに、要求があるときだけ再読み込みをされます。だからパフォーマンスのペナルティを最小限に抑えられます。

== ホットパッチ ==
プロダクション環境では、あなたのコードに「ホットパッチ」を当てることが出来ます。, アプリケーションモジュールのコードを再読み込みしたときにだけ安全にコードを再読み込みします。LiveConsole と連携して、サーバを再起動しなくてもプロダクション環境にパッチをあてることが出来ます。 

== クラスタ ==
サーバクラスタを起動するのは簡単です。待ちうけポートを配列に設定して実行するだけです。：

  rake cluster:start
  To restart, just do:

  rake cluster:restart


== スレッドセーフ ==
いまやスレッドはクールではないとわかっています。しかし、Ruby 1.9 ではネイティブスレッドがサポートされるでしょう。 ほとんどの下品な Web アプリは　理想的なスレッドを作ります。 スレッドはメモリを共有します、これはリクエストを処理するときにたくさんのメモリを確保することを意味します。 そしてもしイベント駆動を使おうと決めても、リクエスト毎にスレッドを使うモデルがオプションであるとわかるとうれしくないですか？これが  Rack のようなスレッドセーフライブラリを使って、Waves がスレッドセーフに書かれているかの理由です。
 
== マイグレーション ==
Waves では Sequel によるマイグレーションをサポートし、使うのに必要な基本的な Rake タスクを定義しています。 マイグレーションは、複数ホスト間で安全なバージョンを提供する最も信頼できる方法で、 Waves はマイグレーションを簡単に使うよう補助しています。

== すべて Ruby ==
Waves はすべて Ruby で書かれています。またライブラリも Waves と同じアプローチを取っています。設定ファイルは Ruby です。リクエストマッピングのルールも Ruby だけです。 Markaby は Ruby のみで書かれています。 Sequel は SQL クエリを Ruby で書けます。 Rack アプリケーションは Ruby だけを使って書かれます。

Furthermore, none of these libraries, including Waves, are intrusive by nature. They add a smattering of extensions to the core Ruby library (mostly via the extensions gem), but they only extend, they don’t override (well, except for RubyGems). So you can use Ruby however you want without unexpected surprises.

Ruby はすべらしい言語です。, why should your framework get in its way? これは Waves とコンポーネントライブラリが採用した基本的なアプローチです。