Categories
open all | close allTags
Subversion | テスト | カテゴリ | Aptana | スキンエンジン | JustPosted | タグ | ドキュメント | フォーム | パソコン | Flash | デュアル・コア | rake | rubygems | 認証 | Migration | 名称 | 国際化 | RESTful | CSRFSearch
Foodynの各機能（仕様）への評価
先日のNucleusの合宿で行ったプレゼンについて，参加者にアンケートを取りました。全部紹介すると大変なので，各機能に付いての評価をまとめたものを図二つにしました。
おおむね好評だったといっていいと思うのですが，Ruby on Railsを使っていることについてはやはり賛否両論分かれました。実績が少ないことでの不安に加え，現在のところホスティングで使えるところが限られてしまうのが理由だと思います。
ただ，PHPやMySQLも5，6年前には安くて使えるところはほとんどありませんでした。Nucleusの最初のバージョンがでてきたころはPHPが広がった時期とほぼ同じではないかと思います。
Railsも後1年くらいでそれくらいのところまで来るのではないかというのが僕の予想です。
ほかにはHTTPの認証について，やはり意見が分かれました。ここも仕方ないところだと思いますが，Foodynではプラグインで別の認証が使えるようにしておく（はず）なので，大きな問題にはならないのではないかと思っています。
限られた時間でのプレゼンだったので，RESTにまつわるところなど説明が足りていない部分もかなりあると思いますが，それでもこれだけ理解してもらったことはありがたいことです。
OpenIDとブログ
FoodynではOpenID対応はプラグインで実現することになると思いますが（～～認証も），この手のログイン用にデフォルトで用意しているユーザーを増やさないといけないなあと思っています。すなわち，これまでだったらログインしている人はすべてメンバーだったわけですが，OpenIDなどが入ると，ログインしているけどゲストって状態があるわけで，ログインしていないゲストと別のロールにしておかないといけません。昨日書いたsafeスキンのフィールドも含めてちょっとテーブルをいじらないと。
テーブルいじること自体はMigration書くだけなので簡単なのですが，Migrationがあんまり多いと配布するときは格好悪いので，どこかでマージして数を減らす必要があります。そうすると既にインストールしている人にテーブルをいじってもらわないといけなくなるなど，また別の面倒が出てくるのが鬱陶しいところ。
複数スキン･エンジンのサンプル
先日のプレゼンについてのアンケート結果は近日まとめるつもりですが，なかで「複数表示エンジン」のところが具体例がないとちょっと分かりにくいかなという話があり。そこで考えてみたのですが，一番簡単で，かつ意味があるサンプルとして，次のようなエンジンを考えてみました。先日のプレゼンでは時間の関係でさらっとしか話しませんでしたが，Foodynではスキン・エンジンに「safe」あるいは「unsafe」の属性が付きます。デフォルトのNucleus互換エンジンは「unsafe」なので，「safe」なスキンしか使えないユーザーはアクセスできません。そこで，Nucleus互換のエンジンを使った「safe」なエンジンが必要になります。
このエンジンでは，ユーザーはスキンの選択はできますが編集できません。indexページに表示するアイテムの数だけが設定できます。
この程度のエンジンだったら簡単に作れますし，イメージつきやすいかなあと。
インライン･テンプレートとヘッダー変数を実装
仕様として書いたからには実装しないと，ということでNucleus互換表示エンジンにヘッダー・スキン変数の機能とインライン･テンプレートの機能を実装しました。ヘッダーの方はごくごく簡単で，コントローラにヘッダを保持するハッシュを用意しておき，プラグインから読み書きできるようにして，スキン変数で書き出すだけです。文字列でなくハッシュにしたのは，同じものが既にないかどうか調べられるようにするため。インライン･テンプレートはスキン変数のパラメータに{}で挟まれた部分があると，そこをJSON（実際にはYAMLのライブラリを使っていますが）として解釈するもの。まだちゃんとデバッグはしていませんが，たぶんそんなに問題はないでしょう。
Nucleusの開発合宿に参加しました
Nucleusの開発合宿に行ってきました（詳しくはこちら）。とはいえ二泊三日のうち中日の日帰りという一部の参加でした。Foodyn CMSについてはこのブログにいろいろ書いてはいますが，見ていない人も多いだろうし，情報がまとまっていないので，この機会にどういうものだか理解してもらおうと，時間を取ってもらってプレゼンさせてもらいました。前の記事のプレゼンはそのための資料です。
午前中に1回と，見逃した人用に夕食後に1回，計1時間近く使わせていただきました。ありがとうございました。これが何かのきっかけになればと思います（Sourceforge.netのDevelopersは一人増えました。^^）。
また，ページスイッチの部分を実装しました。一つのページの中に複数の切り替え用スイッチ（例えば一つはメインブログ，もう一つはサブブログの切り替え用）を置けます。実装は案外苦労しましたが，割と面白い機能になったかと思います。
トップ･ページとレイアウト機能に対応しました
サイト･トップにアクセスしたときに「main」スキンがあったら，そちらを表示する機能と，レイアウト機能，デフォルト･スキン･パートの機能を実装しました。これらを使うと最低限のスキンを作ることがこれまでよりかなり簡単になるだろうと思います。
インライン･テンプレートの機能を加えれば，スキン編集一つだけでも済ませられるようになります。
Foodynのプレゼンを作りました
フルスクリーンで見るにはこちら。管理画面とRESTful
Foodynは基本的にRESTfulなアーキテクチャを採用しています。それが特に顕著なのが管理画面です。RESTfulについてはyohei-y:weblogのREST入門やリコーの研究部門によるドキュメントが分かりやすくまとまっています。またRailsにおける実装についてはRuby on Rails勉強会で翻訳したものが簡潔にまとまっています。
ここではさらに簡単に言うとRESTはリソースをURLで表現し（例えばhttp://example.com/blog/a/item/b でブログaのアイテムbをあらわす），HTTPのverb（GET，POST，PUT，DELETE）でそれに対する操作を決めます。例えば，前述のURLをGETするとブログaのアイテムbを表示し，PUTすると内容を更新し，DELETEすると削除します。実際にはPUTとDELETEは現在のWebブラウザがサポートしていないので，RailsではPOSTとhiddenなフィールドを使って擬似的に実現しています。前述の勉強会の記事ではRESTの操作とRailsで呼び出されるコントローラのメソッドの関係が記述されています。
RESTを使うメリットとしてはリソースと操作が分離されて分かりやすくなること，副作用が伴う操作でGETを使うことはないこと，「ステート」がないためスケールしやすいこと，があります。RESTではHTTPのプロトコルですべてが表現されるというのが基本なのでクッキーも使いません。認証はBASIC認証やDIGEST認証といったHTTP標準でブラウザがサポートしているものを使います。
具体例で示します。Foodynの管理画面では，最初に開いたときにblogのindexを表示します。そこからブログaのアイテム一覧を表示するのはblog/a/itemsというリソース（itemが複数形になっていることに注意）をGETすることです。ブログaに新規アイテムを作るには最初にblog/a/items/newをGETして新規入力用フォームを表示します。入力後blog/a/itemsにPOSTすることにより，新しいアイテムができます。また，ブログaのアイテムbを編集するにはblog/a/items/b/editをGETして，編集後にblog/a/items/bにPUTします。
管理画面の構成
管理画面はレイアウト機能を利用します。レイアウト機能とはメニュー部分など，様々な画面で使いまわす部分をレイアウトとして独立させたもの。Railsではapp/views/layouts/の中に入っています。モデルをRailsのscaffold機能で生成させたりすると，自動的にレイアウトも作られるので，注意が必要です。Foodynにはその名残のファイルも入っていますが実際には使用していません。管理画面ではapp/views/layouts/admin/admin.html.erbというテンプレートを共通で使います。上部と左にメニューを表示します。実際にはコンテキストを見てハイライトする部分を変えるといった処理が必要ですが，今は固定的にメニューを表示しているだけです。
各管理画面のテンプレートはapp/views/adminの下にコントローラごとにディレクトリがあり，その中に入っています。現状はitemsのnew（新規アイテム追加）など一部しか作っていません。
管理画面を作っていくには，RESTfulの考えを理解している必要があります。Foodynの構成において重要な部分なので，これも項を改めて解説します。
Foodynのディレクトリ構成
Foodynの現状のディレクトリ構成を表にまとめました。Railsが標準で作成するディレクトリとFoodynが独自に作っている部分が分かるように，Railsによるディレクトリは黄色で示しています。ディレクトリ構成
以下ではFoodynをいじる人が必要になりそうな部分を説明します。
libのnc_parserがスキンやテンプレートを解釈実行する部分です。parse_xxxといったメソッド名はNucleusを踏襲しています。このディレクトリの中ではbase.rbが汎用のパーサー用メソッドなどを持つベース部分で他のクラスはこれを継承します。なお，Railsの命名規約に合わせて，nc_parserのbase.rbには「NCParser」モジュールの「Base」クラス，すなわち「NCParser::Base」を定義しています。こうしておくことで，アプリ内の他の部分からNCParser::Baseが呼び出されたときに，そのクラスが事前にロードされていなくても，Railsが必要なファイルを見つけてくれます。requireなどを書かずに利用できるわけです。
default_skin_parserはスキンタイプ共通のメソッドを集めており，スキンタイプごとのパーサーは，その子クラスになります。このほかテンプレート，テンプレート・コメント，アイテムをパース実行するクラスがあります。
なお，ここにskinsというサブディレクトリがありますが，使用予定はありません。無視してください。
app/modelsにデータを操作する部分がまとまっています。RailsにおけるMVCのM（モデル）であり，データベースのテーブル一つが一つのクラスに相当します。Railsではクラス名からテーブル名も自動的に決められて設定なしにアクセスできるのですが，テーブル接頭辞とテーブル名の語幹部分の設定を両立できないため，Foodynではテーブル名をモデルごとに明記する必要があります。例えばitem.rbでは「set_base_name :item」という記述が先頭のほうにあります。これでitemテーブルにアクセスします。接頭辞部分はconfig/database.yml内に記述するようにしています。productionとdevelopmentで接頭辞を変えたいといったことに簡単に対処するためです。
また，Railsではテーブル内のidという名称のフィールドをプライマリ・キーとして使用します。プライマリ・キーがないテーブルは書き込みできないなど使用に大きな制限が出るため，FoodynではNucleusが単独フィールドのプライマリ・キーを設けていないテーブルにもidフィールドを加えています。またitemテーブルのinumberなど，id以外の名称のプライマリ・キーがある場合は「set_primary_key :inumber」という指定をします。
モデルによっては内部に多くのロジックを持っています。代表的なのがitem.rb。クラスメソッドのget_listはアイテム一覧を得るための汎用的なメソッド。ページ名や1ページのアイテム数，カテゴリーやタグなどに対応しており，呼び出す側が拡張できるようにもなっています。例えば:orderを指定することでアルファベット順にリストを得るといったこともできます。インスタンス・メソッドのhas_rightは現在のユーザーが特定の権限を持っているかどうかを調べるメソッド。管理画面作成時などに必要になります。
blog.rbとmember.rbの中にもhas_rightというメソッドがあります。管理画面ではmemberに対してhas_rightで権限があるかどうかを調べます。そうするとblogやitemなどに対して権限を調べてもらうためにそれらのhas_rightが呼び出されます。
管理画面に関連するのはviewsのところですが，これについては項を改めて説明します。