ではなく、

<% if model.file_exists? %>
  ...
<% end %>

というのが37signals流。メリットは、

• ビューがすっきりする
• 結果をキャッシュできる
• ユニットテストしやすい
• ローカルファイルシステムから別システム（S3とかMogileFSとか）へ移すことも想定
• MVCとしてモデルがファイルを参照するなら、それがどこにあるかはモデルだけが把握すべき

といったことが挙げられています。

A design and usability blog: Signal vs. Noise (by 37signals)
　http://37signals.com/svn/posts/1944-dont-do-this-if-fileexistsmodel

MOONGIFTではRailsによる受託開発、教育を行っております。そして今回、なぜRailsが良いのかという理由について挙げてみましたのでRails開発に迷いを感じられている方は参考にしていただければと思います。書いてあることは前々から言われているようなことばかりですが…。

まず第一前提としてよく「Railsは生産性が高い」と言われますが、今回は書かないようにしています。目に見えづらく、経験則によるものなのでかえって怪しく見えてしまうからです。数字にまで落とし込めれば良いのですが、正確性がないので今回は省きます。

詳細は以下より。

1. MVCがRailsのみで完結する

Railsはフレームワークであり統合システムプラットフォームです。他言語のフレームワークでは、Webアプリケーションサーバ、ビュー、O/Rマッピングとそれぞれ選定し組み合わせる必要があるのですが、Railsの場合はRailsさえあれば事足ります。ここを縛りと感じるか、不要な選択の手間を省いてくれるかは個人の考え方によります。が、Railsのコンセプトとして「設定より規約」というものがあります。まさにレール（Rail）に乗ることで快適なWebアプリケーション開発が行えるようになります。

選択を不要にすることで開発の開始が速く、知識の均質化がなされるようになります。

2. コーディング量が少ない

RailsはWebアプリケーション開発における基盤となる機能の殆どを実装しています。場合によっては殆どコーディングをせずに済むでしょう。コーディングが少なければバグが潜む可能性も減り、安定した動作が臨めるようになります。

また、多数のプラグインやRubyGemsを使うことにより、一般的な機能（認証やタグクラウド、コメント機能など）をコーディングなしで実現できます。これらの第三者による機能の提供もRailsの魅力になります。

コーディング量を少なくすることで素早い開発が可能になり、さらにバグも抑えることができます。

3. テスト機構が予め組み込まれている

Webアプリケーション開発に限らず、テストを自動化する仕組みはシステムの品質を上げるのに重要な要素になります。Railsではユニットテストを行う仕組みが予め組み込まれているので、ソフトウェアの選定に悩むことなく導入することが可能です。

開発の終盤ではテスト工程が飛ばされることがありますが、Railsを利用することで開発を効率化し、空いた時間をテストに割り当てることでシステムの品質を高め、よりよいものに仕上げることができるようになります。

4. 使い勝手の良いO/Rマッピング

Webアプリケーションにおいてはデータベースが重要な技術要素になります。が、RDBMS（リレーショナルデータベース管理システム）はSQLを介してアクセスするため、通常のプログラム言語とは切り離されて利用されてきました。利用方法が異なるために、SQLインジェクションのようなバグが潜む可能性を高くしています。

Railsで提供されるO/RマッピングシステムであるActiveRecordはそんなデータベースの存在を意識することなく利用できる優れたシステムです。全てRails側で処理を行ってくれるため、複雑なデータを取得する必要がなければ、SQLを書くことはありません。

リレーションに関する情報もRailsのモデル上に定義を行うだけで良く、容易に欲しいデータが取り出せるようになります。

5. Ajaxが容易に使える

これはAjaxを容易に行えるようにするprototype.jsによる力が大きい所ですが。Railsではprototype.jsをJavaScriptのコーディングなしで扱えます。これはprototype.jsの開発者であるSam Stephenson氏が37signals（Ruby on Railsの開発元）に在籍されていることも大きいでしょう。

prototype.jsではなくjQueryが好きな方はjRailsというプラグインを入れることでprototype.jsと同じ書き方でjQueryを使った多彩なアクション、Ajaxを実装できるようになります。

Webアプリケーションを作る上でAjaxの活用は欠かせなくなっています。Railsを使えばAjaxを容易に利用でき、さらにRailsとの親和性も高く簡単に機能を実装できます。

6. 柔軟なバリデーション機能

Railsのモデルにはバリデーションの機能が組み込まれています。データベースの値を参照したり、別な関数の実行結果によって振り分けたりと柔軟なチェックが可能です。モデルに組み込むことで、アクションごとのコーディング量が減り、コードも集約されて変更に対して柔軟に対応できるようになります。

7. 豊富なプラグイン

認証、タギング、コメント、全文検索、ファイルアップロード、ページネーション…Railsがいかに優秀であろうとも、WebアプリケーションにはRailsだけでは足りない機能が多数必要になります。が、それらは世界中の開発者がプラグインという形で開発を行い提供してくれています。これらを使うことで実装するとコーディング量が増えそうなものも、コードレスで実装できるようになります。

認証一つとっても様々な可能性があります。通常のWeb認証に加えてBasic認証やOpenIDを利用することもあります。こうした一つ一つの機能についてプラグインの存在を確かめれば、さらに素早くシステム開発が行えるようになります。

こうした機能をRailsの中に組み込んでしまうとフレームワーク全体が重厚になってしまいます。その取捨選択の妙技がRailsの良さとも言えます。

8. 多数のオープンソース・ソフトウェア

Railsを学ぶ方法は幾つかあります。書籍やWebの情報をもとに自分でコーディングしてみるのも一つですが、他人の書いたコードを見るのも一つです。Railsはその人気の高さもあって、多数のオープンソース・ソフトウェアが存在しています。MOONGIFTでも既に100近くのRuby on Railsを利用したWebアプリケーションを紹介しています。

また、自分の作りたいと思っているWebアプリケーションをオープンソース・ソフトウェアをベースに作り上げていくのも一つの手です。Railsはここ数年のWeb2.0の波に乗って出てきたフレームワークであるため、ソーシャルブックマークやソーシャルニュース、ブログ、マイクロブログ、SNSなど新しめのWebアプリケーションが多数存在しています。これらをベースに改造して自分なりのWebアプリケーションを構築するとさらに素早く構築ができるようになります。

先駆者たちの知識を吸収するのにRailsがオープンソースであることの利点は大きいと言えます。

9. 多数のWeb情報、書籍

数年前では考えられなかったのですが、Webや書籍でのRailsに関する情報は一気に増えてきました。とは言えRails自体の開発速度がはやく、書籍などがすぐに陳腐化してしまったり、最新のバージョンに対応できなくなってしまうことが多々ありますが…。

とは言え、Rails 2.0系（現在は2.1.2が最新）の情報もWebで探すと多数見つかるようになってきています。また、コミュニティに参加するのも良いでしょう。

10. アジャイル開発が行える

コーディング量が少なく機能が実現できるとあって、素早い開発が可能です。そのため、要望の変化にあわせて手早く開発ができるようになります。アジャイル開発では仕様を初期段階できっちりと決めるのではなく、ミーティングを重ねながら徐々にシステムを変えていく必要があります。その点、スクリプト言語であるRubyは変更が手早く反映されるのでアジャイル開発向きと言えます。

他のスクリプト言語に比べて言えば、Railsという柔軟かつ強固なフレームワークの力によりコーディングを少なく手早くアジャイル開発を行えるのがメリットです。

そして最後の理由が、

11. Rubyが日本製

ではないでしょうか。恐らくRubyが海外の言語であったとしたら、日本でここまでもてはやされることはなかったと思われます。とは言え、Ruby on Railsが優秀なフレームワークであるのには変わりはありません。

Railsに関して言えば特に日本語のサポートが充実しているということはありませんが、その元になったRubyが日本製（というよりまつもとゆきひろ氏製）だったからこそ、日本においてもここまでRailsが注目を集めていると言えるのではないでしょうか。

そしてそもそもの題名にある「自社Webサービス」という言葉についてです。個人的な観点で言えば、Railsは他社向けのシステム開発には向いていないと考えています。これらは幾つか要因があるのですが別の機会にて。簡潔に言うと「開発リソースの確保」「パフォーマンス保証」「多様なプラットフォームに対する情報量」などが問題です。そこで他社向けであれば簡易的なものはPHPやPerl、重厚なものはJavaなどを選択するのが良いのではないでしょうか。

自社サービスについて言えば、刻々と変わる利用者のニーズに対して素早く対応していく必要があります。そこには仮定に基づいた実験もあり、それらを素早くフィードバックできる仕組みが必要です。そのとき、アジャイル的な開発に向いたRailsはきっと役に立つはずです。

また、開発会社については未知の技術を使うよりも既知の技術を使った方が保証もでき、安全です。パフォーマンスの面でRailsが問題視されることも多く、最適なアーキテクチャもまだまだ情報が充実していません。その点、自社のWebサービスであれば初期段階は低コストに、利用者やPV増にあわせてシステム増強をはかることが可能です。

MOONGIFTにRailsの受託開発または開発協力を必要とされる方がいらっしゃいましたが、info@moongift.jpまでご連絡ください！

妥協的な方法は以下。

How to Execute a Rails Controller Action via. Cron [ Mr. Matt ]を参考にすると、以下のようになります。


class FunctionWorker < BackgrounDRb::Rails
　def do_work(args)
　　： # 何かの処理
　　app = ActionController::Integration::Session.new
　　posts.each { |some|
　　　app.get "some_controller/some_method/#{some.id}"
　　}
end


こうすると普通にコントローラーが利用できるようになります。やっていることはHTTPアクセスと変わらないので、どうしてもという時だけになるでしょうが。

subLog : HTML / CSS to PDF using Ruby on Rails

答えを言ってしまうと、Prince XMLを使います。各種プラットフォーム向けに提供されているライブラリなので、これを使えば手軽に作成できそうです。そのためのライブラリprince.rbとpdf_helper.rbが公開されています。ちなみにPrince XMLは個人の非商用利用に限りフリーのライブラリなのでご注意ください。

Prince XMLのトップページ

subLog : HTML / CSS to PDF using Ruby on Rails
　http://sublog.subimage.com/articles/2007/05/29/html-css-to-pdf-using-ruby-on-rails

via En attendant Jérémie on Flickr – Photo Sharing!

今回、まともにキャッシュを使おうと思い始めたのですが、ある程度組み上げた段階でキャッシュを組み入れようとすると色々問題が起こることが分かりました。まず知識としては、Railsのキャッシュは3パターンあります。

• Page
• Action
• Fragment

があります。Pageは一番強力で、一度生成後はApacheやlighttpdなどのWebサーバレベルでレスポンスを返してくれます。アプリケーションサーバを通さない分、高速です。が、逆に言えば生成した後はRails側で制御できない状態になるので、表示を細かに変更することはできません。

次にAction Cacheがあります。これはPageアクション同様に生成されるページ全体をキャッシングしますが、Railsのアクションは実行するという点が異なります。アクションを通るので、DBにアクセスして情報を取得することが可能というメリットはありますが、DBへのアクセスがボトルネックになっている場合は使えません。

最後にFragmentキャッシュです。これはViewの中で細かく利用できます。言わば部品を定義していくことで、一部分だけの表示をキャッシングしていくことができます。細かく制御できる利点はありますが、裏を返せば多数使うと管理が大変になります。

では次に問題点や解決策を挙げてみたいと思います。

まず、レンダリングの高速化を考えてできるだけPageキャッシングを使っていきたいと思います。が、ログイン後に出す「○○さんいらっしゃい」という系統のメッセージを出す場合は問題です。これの解決策としては幾つかあるのですが、今回はJavaScriptとCookieで解決しました。

ログイン時にCookieに対してログイン名を渡します。

cookies[:login] = name

これでCookieレベルでログイン名が渡せるようになります。次にビュー側では、


<div id="logged_in">　<%= link_to _("My page"), :controller => :memo, :action => :mypage %>
　(<%= link_to _("Settings"), :controller => :account, :action => :settings %>)
　<%= link_to _("Log out"), :controller => :account, :action => :logout %>
</div>
<div id="logged_out">
　<%= link_to _("Login"), :controller => :account, :action => :login %>
</div>


という形で、ログイン時とログアウト時の両方を書いておきます。その状態でJavaScriptを使います。ここではクッキーの制御が簡単にできるCookieManagerを使いました。

Cookie Manager | Javascript Code | All Things Webby
　http://insin.woaf.net/code/javascript/cookiemanager.html


function handle_cached_user() {
　var manager = new CookieManager({shelfLife:30});
　var logged_in = $('logged_in');
　var logged_out = $('logged_out');
　if(manager.getCookie('login') == null) {
　　logged_in.style.display = 'none';
　　logged_out.style.display = 'inline';
　} else {
　　logged_out.style.display = 'none';
　　logged_in.style.display = 'inline';
　}
　message = manager.getCookie('message');
　if (message != null) {
　　$("notice").innerHTML = decodeURIComponent(message).replace(/\+/g, " ");
　　manager.setCookie("message", "");
　}
}

という風にして、loginというクッキーが存在するならログイン状態に、なければ未ログイン状態としてHTML側の表示を制御しています。この場合の問題点としては、JavaScriptレベルでの制御なので、それを基準にサーバ側の処理は行ってはいけないということがあります。サーバ側は別なセッションなりできちんとアクセス制限を行う必要があります。

が、この方法を使えば、パブリックな情報は殆どPageキャッシュレベルにすることが可能です。

Pageキャッシングの問題として、ページネーションを使った場合の処理があります。これはURLの?以下の文字はキャッシングを別にしてくれないということが問題です。そのため、pageをroute.rbに組み入れておくと、1.htmlのようなページネーションに対応したHTMLファイルを生成してくれるようになります。

map.connect ‘memo/index/:id/:page’, :controller => ‘memo’, :action => ‘index’, :requirements => { :page => /\d+/}, :page => nil

Actionキャッシングは今回は使いませんでした。できるだけDBに接続しないような方法を考えた場合、Actionキャッシングでは中途半端でした。

Fragmentキャッシングは様々な場所で利用しています。例えば、今回はデータベースには簡単なデータのみを保存し、文字情報はAmazon S3に保存しています。これはMogileFSなどの分散化ファイルシステムを使った場合でも同様ですが、HTTPベースでのアクセスになるので速度的に不利です。そのため、必要なデータはキャッシングし、できるだけ接続しないようにしながらストレージを活用していくのが重要です。

当初はモデルのafter_findを使って、データベースからデータを取得した際に、それに関連するデータをAmazon S3から取得する形にしていたのですが、Fragmentキャッシュを利用するにあたって、Amazon S3に極力接続しない形に移行しました。

また、ログインしている否か、マイページなのか否かによって細かく表示を制御している場合、Fragmentキャッシュは相当増える可能性があります。そして増えすぎるとその管理が煩雑になります。そこで解決手段としては、そうした表示上の制御をできるだけ除いてしまうということがあります。ログイン時にしか使えない機能も表示してしまうことで、それがクリックされた際にはログインのページを表示するといった方法や、エラーメッセージを出すという手法をとるようにします。また、それらをJavaScriptで制御するという方法も可能ではありますが、JavaScriptにあまり頼りすぎるのも問題があります。

次の問題として、エラーメッセージがあります。例えばflash[:notice]を使ってエラーメッセージを出した場合、エラーメッセージが表示された状態でキャッシュが作成され、固定化されてしまいます。これだと、別なユーザが見た場合や、再読み込みした場合でも同じエラーメッセージが出続けます。これはCookieレベルでエラーメッセージを出すようにすると解決します。cookie[:message] = “hogehoge”でメッセージを与えておき、表示側でCookieにメッセージがあればそれを表示し、Cookieを消すという動作です。

これらの方法を後から行うと、パブリックなアクションとマイページ系のアクションを別にしたり、レイアウトも別にしたりと修正が相当入ります。元々想定しながら作っておくのが一番です。

PageキャッシングとFragmentキャッシングを活用することで、速度的には相当改善されるようになりました。CookieやJavaScriptたよりになるデメリットもありますが、単なる表示制御だけで、アクセス権限の制御はサーバ側できちんと行っている限りはそれほど問題にはならないかと思います。Railsは他のフレームワークに比べると速度面のデメリットが大きいと思いますので、キャッシングをうまく使って速度向上を行ってみてください。

views/hoge/index.atom.builder内において、

atom_feed({’xmlns:openSearch’ => ‘http://a9.com/-/spec/opensearch/1.1/’}) do |feed|

等と定義しても無視されます。ソースは「actionpack-2.0.2/lib/action_view/helpers/atom_feed_helper.rb」で、ネームスペースっぽい定義が見つからない。

Module: ActionView::Helpers::AtomFeedHelper
　http://caboo.se/doc/classes/ActionView/Helpers/AtomFeedHelper.html#M006099

ここを見る限り、

Other namespaces can be added to the root element:

  app/views/posts/index.atom.builder:
    atom_feed({'xmlns:app' => 'http://www.w3.org/2007/app',
        'xmlns:openSearch' => 'http://a9.com/-/spec/opensearch/1.1/'}) do |feed|

と書かれてはいるのだが、ソースを見る限りできそうにない。で、探してみたらパッチがあった。

#10304 ([PATCH] Atom feed helper should allow to add new namespaces to the feed root element) – Rails Trac – Trac
　http://dev.rubyonrails.org/ticket/10304

86 feed_opts = {"xml:lang" => options[:language] || "en-US", "xmlns" => 'http://www.w3.org/2005/Atom'}
87 feed_opts.merge!(options).reject!{|k,v| !k.to_s.match(/^xml/)}
88
89 xml.feed(feed_opts) do

この辺りが修正範囲。xml〜ではじまっていればネームスペースとして見なす模様。これで無事、Atomフィードに任意のネームスペースが追加できるようになる。

• http://localhost:3000/example/index　HTML
• http://localhost:3000/example/index.rss　RSS2.0
• http://localhost:3000/example/index.atom　Atom

という形で定義します。

Rails2.0の場合は、フォーマットによって出力を簡単に変更できますので、それを使います。

    respond_to do |format|
      format.html
      format.atom {
        render(:layout => false)
      }
      format.rss {
        render(:layout => false, :action => "index.rxml")
      }
    end

これで、Atomの場合は/views/example/index.atom.builderが、RSSの場合は/views/example/index.rxmlが読み込まれます。

Atomのテンプレートは以下のようになります。

atom_feed do |feed|
  feed.title("#{@title} » Example Feed")
  feed.updated(@memos.first.created_at)

  @memos.each do |m|
    feed.entry(m, :url => create_link(m)) do |entry|
      entry.title(m.title)
      entry.content(trans(m), :type => "html")
      entry.author do |a|
        a.name(@user.name)
      end
    end
  end
end

これはベースのようなものです。@memosというリストごとにフィードのエントリーを定義して、タイトルやcontentを作成しています。次にRSS側も同様に処理できます。

xml.instruct!  ml, :version => "1.0", :encoding => "UTF-8"
xml.rss('version' => '2.0', 'xmlns:atom' => 'http://www.w3.org/2005/Atom', 'xmlns:openSearch' => 'http://a9.com/-/spec/opensearchrss/1.0/') do
  xml.channel do
    xml.title @title
    url = url_for(:controller => :memo, :action => :index, :id => @user.name,  nly_path => false)
    xml.link url
    xml.tag!("atom:id", url)
    xml.description(@title)
    xml.language "en-us"
    xml.ttl "40"
    xml.pubDate(Time.now.strftime("%a, %d %b %Y %H:%M:%S %Z"))
    xml.managingEditor(@user.name)
    xml.generator("Jot a Memo")
    xml.tag!("openSearch:totalResults", @memos.paginate.total_entries)
    xml.tag!("openSearch:startIndex", @startIndex)
    xml.tag!("openSearch:itemsPerPage", @perpage)
    xml.guid(url, "isPermaLink" => 'false')
    xml.tag!("atom:updated", Time.now.strftime("%a, %d %b %Y %H:%M:%S %Z"))
    @memos.each do |m|
      xml.item do
        xml.title(m.title)
        xml.tag!('atom:id', create_link(m))
        xml.guid(create_link(m), "isPermaLink" => 'false')
        xml.pubDate(m.created_at)
        xml.tag!("atom:updated", m.updated_at)
        xml.tag!("atom:summary", trans(m))
        xml.link(create_link(m))
        xml.description(trans(m))
        xml.guid(create_link(m))
        xml.author(m.user.name)
      end
    end
  end
end

やたらと長いのですが、あまり気にしないでください。大事なのは、xml.tag!を使うと、<atom:id>…</atom:id>のような形式が定義できるということと、xml.guid(aa, bb)のように二つ目の引数を定義すると、それがattributesになるということです。

後は<rss>の中に拡張書式を定義する場合があると思いますが、それもHashで指定可能です。

このように定義しておくと、次に以下のようなURLを考えた場合も容易に対応できます。

• http://localhost:3000/example/view/id　HTML
• http://localhost:3000/example/view/id.rss　RSS2.0
• http://localhost:3000/example/view/id.atom　Atom

でidで指定されたデータの詳細表示を行う場合です。この場合は以下のように対応します。

    @memos = [@memo]
    respond_to do |format|
      format.html
      format.atom {
        render(:layout => false, :action => "index.atom.builder")
      }
      format.rss {
        render(:layout => false, :action => "index.rxml")
      }
    end

@memoという1件のデータを@memosに配列で入れた以外は、indexと同じ処理になります。実際、フィードで1件を表示する場合も複数件表示する場合も処理は変わらないので、これで対応できます。もちろん、HTMLの場合は異なると思いますので、view.rhtmlは内容が異なるかと思います。

とは言ってもこれではGETだけの対応なので、これからPOST/PUT/DELETEの実装を完了してはじめてAtomPubへの対応が完了したと言えるのですが。

まだ基礎だけですが。とりあえず使うのはGDataライブラリです。

$ sudo gem install gdataSuccessfully installed GData-0.0.4Installing ri documentation for GData-0.0.4…Installing RDoc documentation for GData-0.0.4…

スクリプトは以下のように。
/opt/local/lib/ruby/gems/1.8/gems/GData-0.0.4/lib/gdata/google_contact.rb

require 'gdata/base'
require 'builder'
module GData
class GoogleContact < GData::Base
def initialize
super 'cp', 'gdata-ruby', 'www.google.com'
end

　def list
request "/m8/feeds/contacts/#{@email}/base"
end

　def authenticate(email, password)
@email = email
super email, password
end
end

使い方は簡単で、

require ‘gdata/google_contact’
>> gc = GData::GoogleContact.new
=> #<GData::GoogleContact:0×157cd34 @url=”www.google.com”, @source=”gdata-ruby”, @service=”cp”>
>> gc.authenticate “example@gmail.com”, “[your password]”
=> {”Authorization”=>”GoogleLogin auth=…\n”, “Content-Type”=>”application/atom+xml”}
>> gc.list

でリストがXMLで返ってきます。本当はこれをさらに解析してvCard形式とかでもとれるようになっていると便利そう。実際に返ってくるデータは次のような感じ（整形しています）。
=> ”
<?xml version=’1.0′ encoding=’UTF-8′?>
<feed xmlns=’http://www.w3.org/2005/Atom’ xmlns:openSearch=’http://a9.com/-/spec/opensearchrss/1.0/’ xmlns:gContact=’http://schemas.google.com/contact/2008′ xmlns:gd=’http://schemas.google.com/g/2005′>
<id>example@gmail.com</id>
<updated>2008-03-10T05:05:34.160Z</updated>
<category scheme=’http://schemas.google.com/g/2005#kind’ term=’http://schemas.google.com/contact/2008#contact’/>
<title type=’text’>Atsushi Nakatsugawa’s Contacts</title>
<link rel=’alternate’ type=’text/html’ href=’http://www.google.com/’/>
<link rel=’http://schemas.google.com/g/2005#feed’ type=’application/atom+xml’ href=’http://www.google.com/m8/feeds/contacts/moongift%40gmail.com/base’/>
<link rel=’http://schemas.google.com/g/2005#post’ type=’application/atom+xml’ href=’http://www.google.com/m8/feeds/contacts/moongift%40gmail.com/base’/>
<link rel=’self’ type=’application/atom+xml’ href=’http://www.google.com/m8/feeds/contacts/moongift%40gmail.com/base?max-results=25′/>
<link rel=’next’ type=’application/atom+xml’ href=’http://www.google.com/m8/feeds/contacts/moongift%40gmail.com/base?start-index=26&max-results=25′/>
<author>
<name>Atsushi Nakatsugawa</name>
<email>example@gmail.com</email>
</author>
<generator version=’1.0′ uri=’http://www.google.com/m8/feeds’>Contacts</generator>
<openSearch:totalResults>376</openSearch:totalResults>
<openSearch:startIndex>1</openSearch:startIndex>
<openSearch:itemsPerPage>25</openSearch:itemsPerPage>
<entry>
<id>http://www.google.com/m8/feeds/contacts/moongift%40gmail.com/base/0</id>
<updated>2007-11-26T02:27:10.592Z</updated>
<category scheme=’http://schemas.google.com/g/2005#kind’ term=’http://schemas.google.com/contact/2008#contact’/>
<title type=’text’>Atsushi Nakatsugawa</title>
<link rel=’self’ type=’application/atom+xml’ href=’http://www.google.com/m8/feeds/contacts/moongift%40gmail.com/base/0′/>
<link rel=’edit’ type=’application/atom+xml’ href=’http://www.google.com/m8/feeds/contacts/moongift%40gmail.com/base/0/1196044030592000′/>
<gd:email rel=’http://schemas.google.com/g/2005#other’ address=’example@moongift.jp’ primary=’true’/>
</entry>
：
タイトルにユーザ名が入って、gd:emailのaddressにメールアドレスが入る形ですね。個別で取得する場合はidを利用するようです。その他、住所などのデータも入っている場合は取得できます。とは言え、http://schemas.google.com/g/2005が見られないので、項目の詳細は不明です。

が、メールアドレスのリストだけであればこれで取得できるので便利です。

@memos = @user.memos.paginate(:page => params[:page], :per_page => 10, rder=>”memos.id DESC”)

だけで使えるようになって便利ですが、任意の情報に対してページネーションする方法がいまいち分かっていませんでした。そして、acts_as_searchableを使って、HyperEstraierで全文検索を行う際に、ページネーションをどのように行えば良いのか調べつつ分かったところを書いてみたいと思います。

実際にページネーション処理を行っているのは、

vendor/plugins/will_paginate/lib/will_paginate/finder.rb

になります。ここの

def paginate_by_sql(sql, options)
  WillPaginate::Collection.create(*wp_parse_options!(options)) do |pager|
    query = sanitize_sql(sql)
    options.update  ffset => pager.offset, :limit => pager.per_page

    original_query = query.dup
    add_limit! query, options
    # perfom the find
    pager.replace find_by_sql(query)

    unless pager.total_entries
      count_query = original_query.sub /bORDERs+BYs+[w`,s]+$/mi, ''
      count_query = "SELECT COUNT(*) FROM (#{count_query}) AS count_table"
      # perform the count query
      pager.total_entries = count_by_sql(count_query)
    end
  end
end

が参考になります。

pager.replaceに、リストを入れて、pager.total_entriesに行数を入れればOKのようです。この処理をまねて、

app/controllers/application.rb

に次のように定義します。

module WillPaginate
  module Finder
    module ClassMethods
      def paginate_by_fulltext_search(query, options)
        WillPaginate::Collection.create(*wp_parse_options!(options)) do |pager|
          pager.replace fulltext_search(query, options)

          count_options = Hash.new
          count_options[:count] = true
          count_options[:attributes] = options[:attributes] if options[:attributes]
          pager.total_entries = fulltext_search(query, count_options)
        end
      end
    end
  end
end

です。そして、呼び出し側では次のようにします。

@memos = Memo.paginate_by_fulltext_search(params[:q], :attributes => “user_id NUMEQ %d” % @user.id, :limit => perpage, ffset => offset, :page => params[:page], :per_page => perpage)

ここで、:limitはacts_as_searchable用、:per_pageはwill_paginate用になります。:pageや:offsetは共通で利用できるようです。:attributesはあれば設定します。これさえ設定しておけば、ビュー側は

<%= will_paginate @memos, :prev_label=> _(’« Prev’), :next_label=> _(’Next »’) %>

が利用できて便利です。ちなみにpaginate_by_sqlではoptionsがアップデートされるので、デフォルトの30件になってしまうようですね。これはなぜなんだろう…。