http://www.matsubarafamily.com/lab/ ja Nucleus CMS v3.31SP1 ｩ Weblog http://backend.userland.com/rss http://www.matsubarafamily.com/lab//nucleus/nucleus2.gif http://www.matsubarafamily.com/lab/ http://www.matsubarafamily.com/lab/index.php?itemid=309
ただ，さすがにフォームを作ったり，保存したりといったところは楽です。Railsのリソース･ルーティングにしたがってやっておくだけでほとんどはRailsが面倒見てくれる感じ。慣れたら，管理画面作るのはすいすいできそうです。というわけで，すごくいい加減（例えばデフォルトカテゴリはカテゴリIDを直接入れないといけない）ですが，ブログ設定をFoodynの管理画面で編集できるようになりました。

余談ですが「企業で使えるオープンソースCMS一挙12種類解説」という記事，なかなか参考になります。ステージ管理とか時限発行とか，考えていなかったなあと。時限発行は未来の日付で投稿された記事に対してpingなどを送る機能と同じような形で実現できそうな気がします。有効期限が切れた記事をドラフト扱いにするのか，遠い未来の投稿扱いにするのか，別のフラグを立てるのかといったところがちょっと悩ましいですが。

ステージ管理はどうやったらできるだろう。]]> Foodyn http://www.matsubarafamily.com/lab/index.php?itemid=309 Sat, 5 Jul 2008 05:58:08 +1000 http://www.matsubarafamily.com/lab/index.php?itemid=307 普通にフォーム作っているだけなんだけどなあ。なぜだろう。
というわけでまたも停滞中。ちょっといらいら。]]> Foodyn http://www.matsubarafamily.com/lab/index.php?itemid=307 Fri, 4 Jul 2008 04:59:05 +1000 http://www.matsubarafamily.com/lab/index.php?itemid=305
ここを放っておいて先に進むのは気が進まないのだけど，あまりにここで停滞しているのも何なので，そろそろ先に進むことを考えます。
]]> Foodyn http://www.matsubarafamily.com/lab/index.php?itemid=305 Mon, 30 Jun 2008 03:45:55 +1000 http://www.matsubarafamily.com/lab/index.php?itemid=304 Foodyn http://www.matsubarafamily.com/lab/index.php?itemid=304 Fri, 27 Jun 2008 18:21:20 +1000 http://www.matsubarafamily.com/lab/index.php?itemid=302
で，一応今の管理画面。（）

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メソッドを用意すればいいことが分かります。

これで後はスピードアップするかな？]]> Foodyn http://www.matsubarafamily.com/lab/index.php?itemid=302 Mon, 23 Jun 2008 05:53:18 +1000 http://www.matsubarafamily.com/lab/index.php?itemid=300
結局，map.resourcesなどを使っても楽になっているのかいないのかちょっと微妙な気も…

ルーティングの設定を楽にしたりカスタマイズしやすくする方法については，後でもう一回考えた方がいいかなと思っています。

補遺：前半で書いたことは半ば撤回しました。]]> Foodyn http://www.matsubarafamily.com/lab/index.php?itemid=300 Sun, 22 Jun 2008 05:07:20 +1000 http://www.matsubarafamily.com/lab/index.php?itemid=298   # context is either a Blog, or an Item
  def has_right rightname, context
    #search role first.
    context.has_right rightname, self
  end
rightnameが権限の名前，例えば"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を返します。]]> Foodyn http://www.matsubarafamily.com/lab/index.php?itemid=298 Sat, 21 Jun 2008 06:01:51 +1000 http://www.matsubarafamily.com/lab/index.php?itemid=295
先日デザインパターンの本を読んだのですが，なかなかおもしろかった半面，記述がJavaだったため，Rubyだとどうなるのだろうと気になるところもありました。Javaではインタフェースを中心にデザインパターンを構築することが多いようですが，Rubyだとインタフェースという機能はありません。その代わりにｍｏｄｕｌｅを使ってミックスインしたり，今回のように特に宣言なく同じＡＰＩを用意して呼び出すといったことができます。こういった特質により，デザインパターンの実装も変わってくると思います。

Ｗｅｂ上にはまつもとさんが書かれたものも含め，いくつかＲｕｂｙによるデザインパターンの実装がありますが，できたら体系だって本として読みたいところ。]]> Foodyn http://www.matsubarafamily.com/lab/index.php?itemid=295 Fri, 20 Jun 2008 05:12:56 +1000 http://www.matsubarafamily.com/lab/index.php?itemid=292
考え方としてはゲストというユーザーが必ずTeamに入っていて，そこで権限を設定するというのが一つのやり方。もう一つはblogのテーブルにゲスト・ロールのIDを入れるフィールドを追加する方法。

前者の方が形としてはきれいで，クエリーも1種類で済みそうなのがメリット。ただし，Teamにゲストが入るので，そこだけ特別扱いしないと何か変なことになってしまう恐れがないとも言えません。また，必ずゲストがTeamに入るよう，制御するのもちょっと面倒かも。後者はそういったルールを作らなくて済むのがメリットですが，クエリーはちょっと面倒になるかも。これだとユーザーなしのままで進められというメリットもあります。

ログイン・メンバーだけど，ブログのチームに入っていない場合にどういう扱いにするかという問題もあります。全員チームに入れた上で権限を決めるというやり方はありますが，人数が多くなるとチームのテーブルがn×nのオーダーで膨れ上がります。この場合もブログにログインしているけどチームでない場合の権限へのIDを入れておくのがやりやすそう。

当初はここでシステムロールから権限を決めるつもりだったのですが，そうするとブログごとに設定が変えられない，あるいはブログごとにちがうシステムロールを作らないといけいないことになるので，これまたちょっと面倒なことになります。

パターンが多くてこんがらがりそう。]]> Foodyn http://www.matsubarafamily.com/lab/index.php?itemid=292 Thu, 19 Jun 2008 03:30:39 +1000 http://www.matsubarafamily.com/lab/index.php?itemid=290 フリーの管理画面デザインをRailsのヴューに当てはめているだけ。中身はまだ空です。

それとは関係ないけど一つメモ。Foodyn CMSは複数ユーザーで安全に運用できることを目指していますが，スキンの扱いで一つ考えなければいけないところがありました。例えば，あるユーザーがスキンを選んでカスタマイズする場合，それは他のユーザーには波及しないようにしないといけません。つまり，ブログごとにスキンの複製を作ってからカスタマイズすることになります。また，こういったスキンはブログを消去した際に一緒に削除しないといけません。

Foodynでは，スキン･エンジンごとにduplicateを使うかどうかを設定できるようにしようと思っています。まだその辺の処理は組み込んでいませんが，一応覚書として。]]> Foodyn http://www.matsubarafamily.com/lab/index.php?itemid=290 Sun, 15 Jun 2008 04:13:05 +1000