Categories
open all | close allTags
RESTful | 名称 | フォーム | 国際化 | Subversion | スキンエンジン | 認証 | rake | テスト | タグ | Flash | パソコン | Migration | JustPosted | Aptana | CSRF | モデル | アクセス制御 | ドキュメント | デュアル・コアSearch
初めての管理画面（笑）
とりあえず前言撤回で，RESTfulで用意されているもので大体なんとかできそうな感じがしてきました。deleteのユーザー･インタフェースなど，気になるところもありますが，まずは標準機能で実装していきたいと思います。で，一応今の管理画面。（管理画面）
URLは全部ではないですが，ちゃんとしたものを生成しています。
ここではメモとして，map.namespace付きのprefix付き，ネスティッド・リソースという“テンコ盛り”状態でのルーティングについて書いておきます。
map.namespace(:admin) do |admin|
admin.root :controller =>'admin'
admin.connect ':memberid', :controller =>'Admin'
admin.resources :blogs, :path_prefix=>'admin/:memberid' do |blog|
blog.resources :items
blog.resources :comments
blog.resources :categories
end
admin.resources :plugins, :path_prefix=>'memberid'
endというのがルーティング部分（まだ完全ではありません。必要なとこしか作ってないので）。ここでルートのコントローラを指定することで，アドミン用のコントローラはadminディレクトリの下から選ばれるようになります。アドミンへのアクセスは全部認証付きであり，認証されたユーザー名がmemberidになります。したがって'admin/:memberid'が管理画面のルートです。
その下のresourcesの部分が今日の骨子。ブログ周りのリソース定義をしています。RESTfulなルーティングを使うためにはresourcesが必要です。ここでちょっと注意が要るのがpath_prefixのところ，ここは本来':memberid'だけでいいはずなのですが，それだとURLを生成したときにadminが抜けてしまうバグ？があります。そこでわざわざこれを入れています。
以下でネストされたリソースを加えています。
URLを生成するときはリソースを指定する必要があるのですが，この場合，例えばアイテムの一覧を表示したかったら「admin_blog_items_url(@memberid, blog)」といったリソースをurl_forやlink_toなどのメソッドに渡します。ここで@memberidがユーザー名ですが，これをパラメータに入れるのも一つの肝。プレフィクスを指定しているからなのでしょうけれども，そのあたりの説明はドキュメントになく，試行錯誤で見つけました。なお，admin_blog_items_urlというメソッド名は「rake routes」でルート定義の一覧を出すと分かります。例えば今の部分は
admin_blog_items GET /admin/:memberid/blogs/:blog_id/items {:controller=>"admin/items", :action=>"index"}
といった形で記述されています。これで，今度はAdmin::ItemsControllerのindexメソッドを用意すればいいことが分かります。
これで後はスピードアップするかな？
RESTfulって
基本的にはWebサービスを想定しているから，クライアント機能はサービス内に用意されていないんですねえ，考えてみれば当たり前ですが。管理画面を作るときは結局すべて何かしら画面を通してから処理することになるので，その分のアクションを追加してあげないといけません。結局，map.resourcesなどを使っても楽になっているのかいないのかちょっと微妙な気も…
ルーティングの設定を楽にしたりカスタマイズしやすくする方法については，後でもう一回考えた方がいいかなと思っています。
補遺：前半で書いたことは半ば撤回しました。
権限を調べる部分の実装
まず，Memberのオブジェクトからはhas_rightというメソッドで権限を持っているかどうかを調べます。
# context is either a Blog, or an Item
def has_right rightname, context
#search role first.
context.has_right rightname, self
endrightnameが権限の名前，例えば"browse"などになります。ｃｏｎｔｅｘｔはコメントにもあるように，どのコンテキストで権限を判断するかと言うこと。ブログあるいはアイテムがcontextです。で，これは実際にはコンテキストに問い合わせて調べます。つまり，BlogクラスとItemクラスにはどちらもhas_rightというメソッドがあってそれが呼び出されます。これが昨日書いたダック･タイピング，すなわち同じメソッドを持っていたら同じものとして使える，ということになります。
Blogクラスのこの部分の実装はこう。
def role_of member
if !member
return self.guest_role
else
t = Team.find(:first, :conditions=>["tblog=? and tmember=?", self.id, member.id])
if t then
return t.role
else
return self.user_role
end
end
end
def has_right rightname, member
role = self.role_of member
return role.attributes[rightname]
end
下のhas_rightがメインで，ロールに対してフィールド名で取得するようにしています。実はこれだと関係ないフィールドまで取れてしまいますが，そこはガチガチにしなくてもいいだろうと判断しています。上のrole_ofでは，ログインしていない場合（memberがnil），ログインしているけどチームに入っていない場合，チームに入っている場合に分けてRoleを返します。前二つの場合はBlogのテーブル内のフィールド情報から取り出します。guest_roleやuser_roleはクラスの上の方でbelongs_toとして定義しています。
一方Itemクラスは
def role_of member
role = self.blog.role_of member
itemrole = ItemRole.find(:first, :conditions=>["item_id=? and role_id=?",self.id, role.id])
if itemrole then
return itemrole
else
return role
end
end
def has_right rightname, member
role = self.role_of member
return role.attributes[rightname]
end
has_rightの部分は実は同じですが，ここでもダック・タイピングもどきのことをしています。アイテムで独自の権限を決める場合はその情報はItemRoleというクラスに入っていますが，その場合もRoleクラスと同じようにattributes[rightname]で結果を取り出しています。role_ofの方は先ほどのBlogのrole_ofでRoleを取り出し，ItemRoleが存在すればそっち，しなければ取ってきたRoleを返します。
ダック･タイピング
アイテムでもブログでも区別しないで権限を調べられるように，両者に同じメソッドを作ってアクセスするようにしています。これもダック･タイピングと呼んでいいのかな？先日デザインパターンの本を読んだのですが，なかなかおもしろかった半面，記述がJavaだったため，Rubyだとどうなるのだろうと気になるところもありました。Javaではインタフェースを中心にデザインパターンを構築することが多いようですが，Rubyだとインタフェースという機能はありません。その代わりにｍｏｄｕｌｅを使ってミックスインしたり，今回のように特に宣言なく同じＡＰＩを用意して呼び出すといったことができます。こういった特質により，デザインパターンの実装も変わってくると思います。
Ｗｅｂ上にはまつもとさんが書かれたものも含め，いくつかＲｕｂｙによるデザインパターンの実装がありますが，できたら体系だって本として読みたいところ。
アクセス制御補遺
ちょっとめんどくさいのがゲストの扱いです。まず，ログイン処理するところで，ゲストの場合，ゲストというユーザーにするか，それともユーザーなしにするかという選択肢があります。また，各ブログでゲストに与える権限（Role）を決められるようにしないといけません。考え方としてはゲストというユーザーが必ずTeamに入っていて，そこで権限を設定するというのが一つのやり方。もう一つはblogのテーブルにゲスト・ロールのIDを入れるフィールドを追加する方法。
前者の方が形としてはきれいで，クエリーも1種類で済みそうなのがメリット。ただし，Teamにゲストが入るので，そこだけ特別扱いしないと何か変なことになってしまう恐れがないとも言えません。また，必ずゲストがTeamに入るよう，制御するのもちょっと面倒かも。後者はそういったルールを作らなくて済むのがメリットですが，クエリーはちょっと面倒になるかも。これだとユーザーなしのままで進められというメリットもあります。
ログイン・メンバーだけど，ブログのチームに入っていない場合にどういう扱いにするかという問題もあります。全員チームに入れた上で権限を決めるというやり方はありますが，人数が多くなるとチームのテーブルがn×nのオーダーで膨れ上がります。この場合もブログにログインしているけどチームでない場合の権限へのIDを入れておくのがやりやすそう。
当初はここでシステムロールから権限を決めるつもりだったのですが，そうするとブログごとに設定が変えられない，あるいはブログごとにちがうシステムロールを作らないといけいないことになるので，これまたちょっと面倒なことになります。
パターンが多くてこんがらがりそう。
管理画面設計中
とはいっても，まだやっているのはフリーの管理画面デザインをRailsのヴューに当てはめているだけ。中身はまだ空です。それとは関係ないけど一つメモ。Foodyn CMSは複数ユーザーで安全に運用できることを目指していますが，スキンの扱いで一つ考えなければいけないところがありました。例えば，あるユーザーがスキンを選んでカスタマイズする場合，それは他のユーザーには波及しないようにしないといけません。つまり，ブログごとにスキンの複製を作ってからカスタマイズすることになります。また，こういったスキンはブログを消去した際に一緒に削除しないといけません。
Foodynでは，スキン･エンジンごとにduplicateを使うかどうかを設定できるようにしようと思っています。まだその辺の処理は組み込んでいませんが，一応覚書として。
ブログRole追加だけで終わってしまった
システム系はどういうRightsが必要か考えるのが結構大変だ。でもやっておかないとね，後から拡張するんでもいいけど。
アクセス制御の枠組み
アクセス制御のためのデータ構造が大体決まりました。たぶんこれで行けるでしょう。
ちょっと分かりにくいので図にしてみました。
アクセスはロールごとに決めますが，ロールにはシステム・レベルのものとブログ・レベルのものがあります。システム･レベルのロールはmemberテーブル内に書きますが，ブログ･レベルのものはteamテーブルで指定します。本当は権限については独立したテーブルを用意し，中間テーブルを作ってマッチングさせるのが拡張性が高いのですが，実行速度を重視して，ロールのテーブル内のフィールドとして各権限を設定するようにしました。また，ブログレベルのロールとシステムレベルのロールを区別するためのissystemというフィールドを作っています。このほか，アイテム単位で制御方法を変えられるようにするためにアイテムとロールによるテーブルも作ります。
クエリーの効率が心配ですが，たぶんこれでやりたいことはできる枠組みではないかと思います。
またもやわき道にそれる
管理画面のUIを考えているのですが，そのときにどうしてもアクセス制御のところを入れておかないと気持ち悪くて先に進めません。Foodyn CMSではロール･ベースのアクセス制御を採用する予定です。大体のアイディアはあるのですが，基本的な仕組みのところは作っておかないと管理画面のコーディングができません。簡単なロール･ベースのものなら，世の中にいくらでもサンプルがあると思います。それを使うのも一つの手ですが，今考えているのはブログのチームの概念と組み合わせた制御ができないかどうか。
例えばAというブログがあって，a，b，cの3人がメンバーだとします。またBというブログがあってc，d，eの3人がメンバーだとします。このときにcはAではadminだけどBでは閲覧しかできない，といったアクセス制御をどうやって実現すればいいのか。また，aはAでアイテムが追加できるユーザーで，dはBでアイテムが追加できるユーザーだったとき，この二人を同じロールにできるのか。結構めんどくさそうです。
UI考え中
やみくもに末端の機能から作っていこうかみたいなことも考えたのですが，やっぱりここは肝なのでちゃんとユーザー･インタフェースを考えてから作ろうと，珍しく画面設計からはじめています。しばらくはコーディングともおさらばです。