アップロード画像は変遷がいろいろ激しいみたい
画像をアップロードしてそれを表示に利用するのはとてもよくある処理だと思うんだけど、ゼロから実装するのは意外に面倒くさい。でも Rails には便利な plugin があるので大丈夫。
歴史的なことは知らないんだけど、最近は
の二択くらいな感じみたい。どちらも簡単に扱えるけどどっちかというと Dragonfly の方がより簡単で好きかも。ただし今のところ Dragonfly の方が情報は少ないけど。
Paperclip
migration
README から抜粋すると以下の field を持つテーブルが必要らしい。らしいっていうか、実際試してみたんだけど、このエントリ書くまで日が空きすぎて忘れてしまった。
class AddAvatarColumnsToUser < ActiveRecord::Migration
def self.up
add_column :users, :avatar_file_name, :string
add_column :users, :avatar_content_type, :string
add_column :users, :avatar_file_size, :integer
add_column :users, :avatar_updated_at, :datetime
end
def self.down
remove_column :users, :avatar_file_name
remove_column :users, :avatar_content_type
remove_column :users, :avatar_file_size
remove_column :users, :avatar_updated_at
end
end
Model
上の migration に対応する Model はこうなる。
class User < ActiveRecord::Base
has_attached_file :avatar
...
end
ここで画像用の attribute は avatar になって、file_name やらなんやらは meta data としていい具合に処理してくれるようになる。
View
こんな感じ。
<%= image_tag @user.avatar.url %>
<%= image_tag @user.avatar.url(:medium) %>
<%= image_tag @user.avatar.url(:thumb) %>
今回の例は User モデルに avatar 関連の attribute をそのまま載せているが、分離して association でも処理できる。
form 側はこんな感じ。
<% form_for :user, @user, :url => user_path,
:html => { :multipart => true } do |form| %>
<%= form.file_field :avatar %>
<% end %>
単に file_field に当てはめるだけ。
参考
- websymphony/Rails3-Paperclip-Uploadify at master - GitHub
- association を使った簡単な例
- paperclip の保存ディレクトリ名あるいはファイル名をid連番ではなく、MD5とかSHA1のハッシュ値にするメモ - 超自己満足プログラミング
- [Rails] PaperClipを使って本番の時だけAmazon S3を使う - func09
- [rails] paperclipでAmazon CloudFrontを使う - func09
Dragonfly
http://markevans.github.com/dragonfly/
Paperclip のようにはドキュメントや紹介記事を見かけないけど、コードを覗いていくと storage として file, mongo, s3 が使えるみたい。
下準備
config/initializers/dragonfly.rb
require 'dragonfly/rails/images'
migration
最低限一つだけ field があればよいみたい。
class MyMigration < ActiveRecord::Migration
def self.up
add_column :albums, :cover_image_uid, :string
end
def self.down
remove_column :albums, :cover_image_uid
end
end
Model 上でどんな attribute に画像を紐づけるか決めて、
#{attribute}_uid
があれば ok.
Model
上の migration に対応する最低限の Model の記述は
class Album
image_accessor :cover_image
end
image_accessor で attribute を指定するだけ。すると以下のような感じで meta data を取れる。
@album.cover_image.width
@album.cover_image.height
@album.cover_image.number_of_colours
@album.cover_image.mime_type
View
<%= image.caption %></th>
<%= image_tag( image.photo.process(:thumb, '240x240#').url,
{:size => '240x240', :alt => image.caption} ) %>
こんな風に書ける。
form 側は
<% form_for @album, :html => {:multipart => true} do |f| %>
...
<%= f.file_field :cover_image %>
...
<% end %>
同じ要領ですな。
注意
当たり前だけど image_tag を生成すること。でないと表示されない。
今年に入って日記の更新頻度がガタ落ちしてますが、別にバーンアウトしたわけではないし、Twitter の方に細かい思いつきや文句を吐き出せて満足しているのもあるけどそれだけでもないです。
いちばんの理由はある程度以上の長さの日本語を書く気力すら残らないほどヤラレているからです。
Fastladder はいつも pin 留めが 100 を越えてから本文を読み始める始末だし、ブックマークの方もタグすらつけてないものが多くなってきていよいよ訳が分からなくなりそう。1まぁ本文を読んでないだけでフィードに目を通す時間はまだ確保できてる分マシなのかもしれないけど。年末から Amazon で頼んだけど配送予定が立たず、リアル店舗を探し回ってまでゲットした本が何冊もあるのに全然読めてませんT_T
まだしばらくはこんな感じかなぁ。ま、身体も心も病んでないのが幸い。単に体力がなくて無理が効かないだけとも言う。世の中にゃこれに加えて毎日通勤地獄に耐えている人がゴマンと居るわけだから恐れ入るよね、まったく。
最近やっと気づいたけど、自分の場合は調べもの以外では読む時間がない方がブックマークは多くなる傾向があるらしい。 ↩
……と、ここまで書いてたんだけど実は今ならはてなブックマークに全部丸投げでもいいかもね。APIで全コメントを取得してページのフッタにべろっと展開して、ブログの画面のコメント入力欄のように見えるフォームは、実はb.hatena.ne.jpにポストするという。
実はコメント欄のない splash star を見て、「ぶくまでも始めるか」と思っていた。でも本家にコメント欄がつくならそれ使おうっと。
でも何に対してコメントつけようと思っていたのかはもう忘れた。
あとで申し込むメソッドを日記でやるテスツ。
GMail アカウントあればどこからでも申し込みできて便利かなぁ。Gmail Invite もついでに please してみるテスツ。
※ 自宅サーバに IMAP ってのは ToDo には入ってるんだけど、そんなに強く必要性を感じないし面倒くさいので進んでません。
Amrita に inspire された PHP 用のテンプレートエンジン。個人的にはこれが本命だな。しかしサイトが丸ごと phpDocumentor の出力結果ってのがまた豪気だ。
DB が要らなくて PHP だけで動くツールって少ないからね。blosxom は書き手が HTML を使えることを前提にしている感じはするけど、それこそ local の Wiki で書いてできあがった HTML を貼り付けちゃえばいいと考えているので、自分および職場の環境として悪くない。なんとなれば PHP で動いている本番サーバでも活用可能なのが PHPosxom なわけだ。おっほっほ。テストテストだぜ。
from http://slashdot.jp/comments.pl?sid=160835&cid=503611
便利なのか？ デルタってなんだ？ それより cvsup は fw を自由にできない環境では使いにくいものだったのか。知らなかった(^^;
いやだいやだと言いながら使い続けている tDiary. まーここの日記はそのまま行くかもしれないけど、説教講座はこれだとちょっと使いにくいかなぁという気がしていた。で、これの代わりに blosxom を試してみようと思い始める。以前も一応チェックだけしていたんだけど、結局何もしなかった blog ツールをいよいよ試してみるぞってことですな。MySQL などの DB をバックエンドに要求する blog ツールが多くなっている中、blosxom は Pure Perl で完結しているところがいい。別に DB 前提でも悪くないんだけど、なんだか大げさな感じするし、ちょこっとデータを直そうと思ったときに Zope みたいな ODB じゃない、伝統的な RDBMS はちょっと扱いにくい。そこまで膨大なデータ量でもないし、パフォーマンス低下よりもバックアップとかを考えるとコストの方がでかいんじゃないかな、DB 前提のものは。
blog って、別に CGI でデータを更新しなくても blog なのね。まぁその方がクライアントサイドでも工夫ができるので、そういう点はいいよな。つーことで下書きを Wiki でやって、できた HTML を上げて blosxom で表示、つースタイルがよさげな気がしている今日この頃。アイディアとしては今職場のサイトで採用している include_html() と同じようなもんなのかもしんないな、もともと blog って。要するに更新部分だけを更新しやすくすることがスタート地点なのであって、trackback だの theme だのなんて後付けじゃねーかと。