まったりRails (その2)

Ruby

さて、データベースの設定も終わったことだし、実際にアプリケーションを動かしていこう。
といっても、動作を確認するだけのアプリケーションならば、大してやることは無い。先日、実行したコマンドを書いたが、その中の一つで既にアプリケーションのコントローラとなるクラスを生成しているのだ。

cd www
rails sample
cd sample
ruby script/generate controller info

最後のコマンドにより、railsはアプリケーションのディレクトリ(www/sample/app/controllers/)に、コマンドで指定された"info"という名前の付いたスクリプトを生成するのだ。

  • info_controller.rb
class InfoController < ApplicationController
end

これで、http://localhost:3000/infoのリクエストに反応することができるコントローラクラスが用意された訳だ。
次にすることは実際に動作する「アクション」を定義していくことだが、アクションに関してはこのコントローラのインスタンスメソッドとして実装するのがRailsの標準的な考え方だ。

では、後々、メソッドであーだこーだといろいろすることを妄想しつつ、今は空のメソッドを追加しよう。

  • info_controller.rbにhelloアクションを追加する
class InfoController < ApplicationController
  def hello
  end
end

これでhttp://localhost:3000/info/helloへのリクエストに反応するメソッドが出来た。
railsのデフォルトではアクション・メソッドは処理の後、同名の名を持つビューを呼び出そうとするので、www/sample/app/views/infoにhello.rhtmlを置くことで一つのアクションを完結することができる。

  • hello.rhtml
こんにちはRails
  • 実行結果


実にわかり易くシンプルな仕組みだ。


railsに限らず、Webアプリケーションを作る仕組みとしてリクエストするURLを言語の実装にマッピングする仕組みは、昔からいろんな人が同じように考えてきたものだ。
私も例に漏れず、最初にJavaのフレームワークを書いた時には同じことを考えた。ただし、それはrailsのようにではなく、Struts等と同様に論理的なパスを設定ファイルに書き、それをクラスにマップする設計としていた。

当時まだ経験の浅いプログラマに、「呼び出すURLのパスをクラス階層とメソッドに直接マップしたほうが解り易いんじゃないですか」と言われたことを思い出す。

どうしてそれがすぐに出来なかったんだろう。