Categories
open all | close allTags
タグ | nextlink | パソコン | 認証 | アクセス制御 | カテゴリ | RESTful | モデル | rake | 名称 | フォーム | Aptana | スキンエンジン | プラグイン | 抽象化 | CSRF | Migration | デュアル・コア | テスト | OpenIDSearch
力づくで解決
あまり，ここでばかり時間を費やしたくないので，コメントフォームを作ったときと同様，CSRF対策用のタグを手動で埋め込むことでとりあえず先に進むことにしました。ただ，さすがにフォームを作ったり，保存したりといったところは楽です。Railsのリソース･ルーティングにしたがってやっておくだけでほとんどはRailsが面倒見てくれる感じ。慣れたら，管理画面作るのはすいすいできそうです。というわけで，すごくいい加減（例えばデフォルトカテゴリはカテゴリIDを直接入れないといけない）ですが，ブログ設定をFoodynの管理画面で編集できるようになりました。
余談ですが「企業で使えるオープンソースCMS一挙12種類解説」という記事，なかなか参考になります。ステージ管理とか時限発行とか，考えていなかったなあと。時限発行は未来の日付で投稿された記事に対してpingなどを送る機能と同じような形で実現できそうな気がします。有効期限が切れた記事をドラフト扱いにするのか，遠い未来の投稿扱いにするのか，別のフラグを立てるのかといったところがちょっと悩ましいですが。
ステージ管理はどうやったらできるだろう。
またもやInvalidAuthenticcityTokenでエラー
とりあえずブログ設定のフォームなど，作ってみたりしているのですが，保存しようとするとInvalidAuthenticityTokenエラーが出てしまいます。普通にフォーム作っているだけなんだけどなあ。なぜだろう。
というわけでまたも停滞中。ちょっといらいら。
状況変わらず
Simple Localiaztionのバージョンを上げてみたのですが，状況は変わりません。動いていた部分も動かないのでちょっと困惑。バージョンが上がって大分変わっているみたいだし。とりあえずフォーラムに質問を投げてみたけどどうなることか。ここを放っておいて先に進むのは気が進まないのだけど，あまりにここで停滞しているのも何なので，そろそろ先に進むことを考えます。
言語ファイル
最近，どうも夜集中力が続かないのですが，このところ何をしているのかというと，管理画面用の言語ファイルを設定しようとして，意外に苦戦しています。設定はあっているようなのに，どうして動かないんだろう。プラグインのサイトのドキュメントを見ようとしたらApacheのエラーで落ちていたりとか。ちょっといらいら。RESTfulって
基本的にはWebサービスを想定しているから，クライアント機能はサービス内に用意されていないんですねえ，考えてみれば当たり前ですが。管理画面を作るときは結局すべて何かしら画面を通してから処理することになるので，その分のアクションを追加してあげないといけません。結局，map.resourcesなどを使っても楽になっているのかいないのかちょっと微妙な気も…
ルーティングの設定を楽にしたりカスタマイズしやすくする方法については，後でもう一回考えた方がいいかなと思っています。
補遺：前半で書いたことは半ば撤回しました。
ダック･タイピング
アイテムでもブログでも区別しないで権限を調べられるように，両者に同じメソッドを作ってアクセスするようにしています。これもダック･タイピングと呼んでいいのかな？先日デザインパターンの本を読んだのですが，なかなかおもしろかった半面，記述がJavaだったため，Rubyだとどうなるのだろうと気になるところもありました。Javaではインタフェースを中心にデザインパターンを構築することが多いようですが，Rubyだとインタフェースという機能はありません。その代わりにｍｏｄｕｌｅを使ってミックスインしたり，今回のように特に宣言なく同じＡＰＩを用意して呼び出すといったことができます。こういった特質により，デザインパターンの実装も変わってくると思います。
Ｗｅｂ上にはまつもとさんが書かれたものも含め，いくつかＲｕｂｙによるデザインパターンの実装がありますが，できたら体系だって本として読みたいところ。
ブログRole追加だけで終わってしまった
システム系はどういうRightsが必要か考えるのが結構大変だ。でもやっておかないとね，後から拡張するんでもいいけど。
アクセス制御の枠組み
アクセス制御のためのデータ構造が大体決まりました。たぶんこれで行けるでしょう。
ちょっと分かりにくいので図にしてみました。
アクセスはロールごとに決めますが，ロールにはシステム・レベルのものとブログ・レベルのものがあります。システム･レベルのロールはmemberテーブル内に書きますが，ブログ･レベルのものはteamテーブルで指定します。本当は権限については独立したテーブルを用意し，中間テーブルを作ってマッチングさせるのが拡張性が高いのですが，実行速度を重視して，ロールのテーブル内のフィールドとして各権限を設定するようにしました。また，ブログレベルのロールとシステムレベルのロールを区別するためのissystemというフィールドを作っています。このほか，アイテム単位で制御方法を変えられるようにするためにアイテムとロールによるテーブルも作ります。
クエリーの効率が心配ですが，たぶんこれでやりたいことはできる枠組みではないかと思います。
タグとカテゴリが曲がりなりにも動いたので
そろそろ次のフェーズ（管理画面）に入ろうかと。あー腰が重い。
まずは投稿画面からかな。
設計とメソッド名と内部構造
どうも頭がまだ手続き型言語から抜けていないようで，メソッド名を付けるときに，ついつい「get～～」みたいに動詞を入れてしまいがちです。ということに気付いたのは，あるブログに属するカテゴリー一覧を取得するとき。実はこれまでCategoryクラスの方でget_listというメソッドを作ってブログオブジェクトをパラメータに取得するようにしていました。こうしておくと，ブログが指定されないときの一覧やブログが複数あるときの一覧とかも同じメソッドで取れるというのがメリットなのですが，見直してみるとCategory.get_list ... と入るのはあまりきれいじゃないです。やはり blog.categories と書いた方がスマート。
これだと順序付けができないのかと思って，この記述を使っていなかったというのもあるのですが，APIを見たら has_many のリレーション指定の中で :order を使って指定できることが分かったので，今回はそちらに切り替えました。
ただ，しっくりこない面がないわけではありません。これだとBlogクラスの中でCategoryのテーブルの内部情報を使って :order のところを書くことになるため，Categoryの実装に完全に依存してしまいます。Categoryの内部構造が変わったらBlogクラスも変えなければいけないのでメンテナンス性が悪くなります。
どうするのがベストなんでしょう。