Categories
open all | close allTags
タグ | テスト | アクセス制御 | 国際化 | Subversion | RESTful | OpenID | 認証 | 名称 | パソコン | Flash | ドキュメント | Migration | モデル | Aptana | フォーム | スキンエンジン | rake | デュアル・コア | CSRFSearch
原因究明＞泣きたくなった【追記あり】
InvalidAuthenticationToken問題の解決がやっと見えてきました。簡単なサンプルプログラムを作って，そこでの動作といちいち比較するというかなりしんどいデバッグでした。問題点の一つはコントローラでlink_toをしているところ。実はコントローラではlink_toはサポートされておらず，ビューにしかこのメソッドはありません。で，自分でも忘れていたのですが，これを「self.class.helpers」にdelegateで渡すといった記述をしていました。ところが，これだとビューはビューでも新しいビューを作ってそれに渡すことになり，そこでコントローラとの連携が切れてしまっていたのでした。デバッグ中に調べていくとコントローラの@templateというインスタンス変数がビューを格納していたので，それに渡すように変更しました。
次に，それでも途中で，CSRF対策機能を使うかどうかをチェックするprotect_against_forgery?というメソッドが何も実行しないで返ってきてしまう。これにすごく悩んだのですが，実はこれも自分のせいであることが判明。ヘルパーになぜかこの名前のメソッドを作っており，中身が空っぽだったのです。きっと，自分で代わりになる機能を入れようとか考えていたのだろうと思うのですが全く記憶にありませんでした。中身が空のメソッドはデバッガが飛ばしてしまうため，そこに行っていることに気付きませんでした。プロジェクト内に検索をかけてようやく発見。
これだけでおおよそ4時間。疲れました。しかも全部自分のせいだし…
これでほかのところも動いてくれるといいのですが。
【追記】
これでほかのフォームにもCSRF対策用のフィールドが自然に入るようになりました。こりゃ確かに検索しても原因が分からないのは当然です。今後の作業は大分スムーズになるのではないかと思います。
思いつきメモ（アイテムやカテゴリーとスキンの紐付け）
アイテム単位でスキンを指定できるとちょっとうれしいかなと思いました。きっかけは卑近なところですが，メインのブログの方で毎月のトップアクセスの記事をまとめているときのことでした。毎月上位に来る記事というのは割と決まっているので，そこが一種のポータル的な役割になるようにページを変えられないかと思ったのです。GoogleのAdSenseなど，内容で広告を動的に変えるものはありますが，全部が自動的に最適になってくれるわけではないし，NP_Relatedみたいなブログ内の関連記事を自動的に探すのもちょっと限界があります。そこでアイテム単位でスキンを変えられると，もっと柔軟な対応ができるかなと思ったわけです。
Twitterでつぶやいてみたところ，カテゴリーもほしいという声も。確かにスキン中のifで制御できるとはいえ，大きく変えたい場合は別スキンに書けるとすっきりしそうです。
実装は二つ考えられます。一つはアイテムやカテゴリーにスキンIDのフィールドを作ること。モデル実装上はこれがきれいで，Nucleus互換エンジン以外にも対応できますが，アイテムごとにまるまる新しいスキンを置くのはかなりおおげさな感じがします。メインと同じスキンの上でできた方が作りやすい。
そこで考えたもう一つの実装はスペシャルスキンパーツを使うもの。例えばitem_333というスペシャルスキンパーツがあったら333というアイテムの表示のときにそれを使います。使い回しはちょっとやりにくくなりますが，それほど多用するものでなければ，これがよさそう。同様にcategory_17などとするとID17のカテゴリー表示にそれを使います。タグも同じようにできると思います。この実装はNucleus互換エンジンだけの機能になってしまいますが，今はこれで実装するつもりです。
鬼門に遭遇
前から問題になっているInvalidAuthenticityTokenのエラーにまた遭ってしまいました。デバッガーで追いかけて，ちゃんとCSRF対策用トークンを入れてくれるときと何が違うのか調べようとしているのですが，なかなか分かりません。
現象が分かったとしても解決策まで分かるかどうかも問題だし。
検索しても同じような問題にあっている人がいなさそう。よほど特殊なことをしているんでしょうか？
このところの生産性の低さに嫌になります。
プログラマ向けの性格
Foodyn CMSの設計を考えるときの方針としては「どういう使い方をしたいか」「どうしたら使いやすいか」をなるべく先に考え，それを実現するために，データ構造やプログラム構造を考えていくようにしています。プログラムのレベルでも同じで，プラグイン作者などに気持ちよく使ってもらえるためにはどうしたらいいかを結構一生懸命考えています。プラグイン用のマイグレーションは，その成果の一つですし，このところクロージャ周りでいろいろやっているのも関連しています。
で，表題の「プログラマ向けの性格」という話ですが，つまるところは「後で楽をするために，先に苦労することを自然にできるか」ということになるような気がしています。Railsの思想でいえばDRY（Don't Repeat Yourself）が自然に考えられるか，ということです。
例えば同じことを何回も繰り返さなければいけない単純作業があったときに，「とにかくやろう」とその単純作業にひたすら取り組む人はあまりプログラマ向きではありません。どうやったらその単純作業が効率よくできるか，最初にいろいろ調べたりテストしたりして考える人はプログラマ向きです。
実世界では，多くの場合プログラマ向きじゃない方法，つまり単純作業に脇目もふらずに取り組む方が，効率を考える人よりも早く作業が終了してしまいます。そうすると，最初になんだかんだやっている人は「あいつはくだらないところにエネルギーを使って」と低く評価されてしまいます。特に日本の社会ではそういう面が強いような気がします。
結局は，どっちがいいかの見極めが上手だと，世渡りもうまくいくのかもしれませんが，そのあたりのバランスは難しいですね。
（Twitterで似たような話題が出ていたので，ちょっとまとまってませんがアップしてしまいます）
管理画面の抽象化と権限チェックの強化
あまり成果が上がっていない話ですが，引き続き管理画面の抽象化を考えています。どういうことかというと，表示する内容（メニューの文字やリンクなど）と，表示を制御する部分（CSS，HTMLのタグなど）を分け，さらにそれらを表示ロジックと分離させたいのです。ここまでできると，管理画面がほとんど着せ替えに近い格好で変えられ，さらに管理画面の機能強化も容易になります。
前述のようにテーブルについては既に完成し，かなりのロジック軽減につながっているのですが，メニュー表示などに広げるかどうかが悩みどころ。もちろん分離は可能なのですが，ロジック側や表示側の手間がかなりかかってしまい，どうもメリットがあるのかないのか微妙なところ。今は使わない方向で動いています。
もう一つ考え中なのが，管理画面での権限チェックを忘れない方法。
管理画面ではアクションごとに権限のチェックが必要ですが，権限のチェックをしなくても動いてしまうため，セキュリティ・ホールを作ってしまうおそれがあります。そこで権限のチェックをしていないときに動かなくするか，メッセージを表示するような仕組みを入れておきたいと思っています。今，これを書きながら一つアイディアが浮かんだので試してみます。
結果：AdminControllerにinitializeメソッドを作り，そこで@right_checkedというインスタンス変数をfalseで初期化します。権限チェックのメソッドで，これをtrueに変えます。ビューを実行するときにこの変数を見て，falseだとエラーメッセージを出すようにしました。
で，結局
fields_forとcheck_boxの組み合わせはあまりにも複雑になってしまうため，シンプルなcheck_box_tagで出力するほうがよほどまし，ということになってしまいました。泰山鳴動して鼠一匹。ファーム要素がセンタリングされるのが気持ち悪いのですが，世の中にCSSほど苦手なものはないので，しばらく解決する気なしです。
ああ徒労。
fields_forに惑う
ここ数日，更新がないのは作業が進んでいないからです。フォーム系の配列表示対応をしているのですが，アイテム入力のフォームで，カテゴリー入力のところを変えようとしてはまっています。
これまでは以前のバージョンからあるcheck_box_tagを使って，オブジェクト処理と無関係に処理を作っていたのですが，fields_forを使ってもうちょっとオブジェクトっぽくしようと考えています。複数のモデルを処理するフォームの例はいくつか本などに載っているのですが，それでは十分でなかったり，やってもてもうまくいかなかったりして，今にいたっています。
思いつきメモ
スキンについての思いつき。Google Groupsに書いたら思い切り文字化けしたのでこっちに転載します。Foodynのスキンにはデータセットという概念があります。例えば
<%dataset(5)%>
とすると，そのページにはアイテムを五つ表示するということになり，ブログやページスイッチでは指定が不要になります。
<%blog(template)%>
<%pageswitch(template)%>
で済んでしまうわけです（templateも省略できますが）。
名前を付けることもでき
<%dataset(name,10,blogname)%>
みたいなことができます（今のところブログ名部分は未実装ですが）。
こうすると，先ほどの指定も
<%blog(template,name)%>
<%pageswitch(template,name)%>
となり，名前付きでないページスイッチと同一ページに共存できます。
データセットの機能は，暗黙的にも使われており
<%blog(template,10)%>
と書くのと
<%dataset(10)%><%blog(template)%>
と書くのは内部的には同じことです。
というわけで実は<%otherblog%>というのはもはや不要だったりするのですが，それはそれとして今日書くのは別の話。
ブログの表示を2段組にしたいとか，トップ二つの記事は要約を付けて，後はタイトルだけにしたいとか（ニュースサイトのように），そういう希望にも応えられるようにしたいと考えています。そのためには同じデータセットの中で表示するアイテムを分割指定できるようにする必要があります。
と，ここまで考えたのですが，どういう指定法にしたら柔軟，かつ簡単に使えるかというところでちょっと思考がストップ中。アイディアをお待ちしております。
スキン周りに関する仕様のまとめ
Nucleusのスキン周りについてTwitterでいろんな話が出ていたので，Foodyn CMSにおける仕様と実装についてまとめておきます。Foodynはスキン（他のCMSだとテンプレートといったほうがいいのかな？）の処理系（エンジン）を複数載せられますが，ここでは標準組み込みであるNucleus互換のスキン・エンジンについてだけまとめます。
まず，現状のNucleusのスキンには分かりやすさなどにおいていくつか問題があります。
①DBに保存されているスキンと，ファイル・ベースでインクルードする部分があり，編集画面もそれぞれ別になる
②さまざまなスキンタイプが分かりにくい
③スキンとテンプレートの関係が分かりにくい。テンプレートの中にはアイテムの表示に関係するもの，カテゴリーの表示に関係するもの，さらには日付表示に関係するものや，画像表示に関係するものなどが混在しており，どこで何が使われているのか理解するのが難しい
④特別なページを作る機能が少ない
Foodynではこれらについて次のような改善策を取ります。
①Nucleusのスペシャルスキンパーツをインクルードする機能を標準で持ちます（Nucleusでファイルをインクルードするのに使うparsedincludeを拡張）。基本的にDBベースの編集だけで済むようになります。
②「レイアウト」スキンを使うと，各スキンに固有な部分（例えばアイテムページにおける<%item%>スキン変数）はデフォルトのものが利用でき，何も作らなくて構わない（もちろんデフォルトで不満がある場合は作っても構わない）
③テンプレートにデフォルト機能があるので，意識してテンプレートを使わなくてもよくなります。例えば<%categorylist%>だけで動くようになります。また，インライン・テンプレート機能を使うことで，スキンの中にテンプレートを埋め込めます。
また，スキンに対してメインのテンプレートとアイテムスキン用のテンプレートという二つのテンプレートを属性として持つようにします（未実装）。標準ではスキン名に「/index」「/item」をつけたものがテンプレート名になります。これらはスキンのデフォルトテンプレートとして働きます（ない場合はシステムのデフォルトが使われます）。
これらのスキンに付属するテンプレートはスキン編集画面から直接パート（例えばカテゴリ表示関係）ごとに呼び出して編集できるようにします（未実装）。
④ブログに付属しないアイテムを作ることができ，このアイテム・ページに自由に名前を付けることによって，さまざまなページが作れます。
トップ・ページの機能があり，トップページだけ専用のスキンパートを利用できます。
表出力の抽象化
管理画面の基本は表です。ブログやアイテムの一覧はもちろん，フォームもラベル部分と入力部分で表を使って表示することが多いと思います。そこで，管理画面の出力内容と表示を分離するため，表出力を抽象化してみました。
まず，出力内容はコントローラで次のような形で設定します。
def index
@blogs = @member.blogs
@table.header=[la('Blog Name'),la('Add Item'),la('Edit Item'),la('Comments'),\
la('Tags/Categories'),la('Settings'),('Delete Blog')]
@table.widths=[177]
@table.data = []
@blogs.each do |blog|
row = []
row << h(blog.bname)
row << context_link(new_admin_blog_item_url(@memberid, blog),blog,"commit", "page_add","add item")
row << context_link(admin_blog_items_url(@memberid, blog), blog, "commit", "page_edit","edit items")
row << context_link(admin_blog_comments_url(@memberid, blog),blog,"commentedit", "comments","comments")
row << context_link(admin_blog_categories_url(@memberid, blog),blog,"commentedit", "tag_red","categories")
row << context_link(edit_admin_blog_url(@memberid, blog),blog,"editsettings", "application_edit","settings")
row << context_link(admin_blog_url(@memberid, blog), blog,"deleteblog", "folder_delete","delete blog", \
:confirm=>'OK?', :method=>'delete')
@table.data << row
end
render
endここで@tableが表を抽象化したTable型のオブジェクトで，@table.headerに表頭，@table.widthsに列幅指定（あれば），@table.dataに表のボディ部分が入ります。
一方，表示側は
def show_table table
temp = <<HEAD
<div class="table">
<img src="/admin/img/bg-th-left.gif" width="8" height="7" alt="" class="left" />
<img src="/admin/img/bg-th-right.gif" width="7" height="7" alt="" class="right" />
HEAD
table.controller self
temp += table.html do |h|
h.options({:class=>'listing', :cellpadding=>"0", :cellspacing=>"0"})
h.head({:first=>'first', :last=>'last'})
h.body({:first=>'first style1', :last=>'last', :cycle=>[nil, 'bg']})
end
temp += '</div>'
endここでパラメータで与えられたtableが先ほどのTable型のオブジェクト。これに対して，table.htmlというメソッドで表の表示内容を指定しています。管理画面のすべての表に対して，このshow_table一つで対応できます。後はコンテンツ側を変えるだけ。
これで表部分はいいのですが，問題は表に入らないような要素がある場合。例えば，管理画面のトップページである，今の画面には新規ブログを作るボタンがあります。そこの部分は抽象化していないので，ビューに素のHTMLを書くことになってしまいました。今後はこういった要素の抽象化をするのか，あるいはこういった要素を排除していくのか考えていったほうがよさそうです。