Foodyn CMS開発日誌

URL設定

Mon, 5 Jan 2009 17:52:53 +0900

年末から年明けにかけてMovable TypeのブログをWordPressに移行するブログ記事がいくつか出ていました。やっぱり長くやっているブログだとURLを変えずに移行するというのは大事でしょうね。

Foodynでは現状のルーティングは割と固定的になっているのでパーマリンクに年月日を入れるような形式には対応していません。以前からここはどうしようか悩んでいるところではあったのですが，これらの記事を読むと，もっと自由度を高めるべきなのでしょうね。Railsのルーティングで認識する部分は最小限にして，Foodyn側で大部分の処理をするように変える必要があります。ちょっと悩ましいところですが，「いつかはやらないといけないんだろうなあ」と思っていた部分なので，後押しされた感じです。

今は管理画面の方を優先しますが，その後で，そちらの調整をしたいと思います。

Railsでダイジェスト認証サポート

Mon, 5 Jan 2009 10:34:39 +0900

Edge Rails（開発版）にダイジェスト認証の機能が入ったそうです。これはうれしい。認証部分がプラグイン不要になります。

前のエントリーで書いたRails Enginesについては組み込みはしたもののまだ使い方を調べ中。ルーティングにどのプラグインのルートを組み込むか書かないといけないようで，その部分をどうやって自動化させるかがちょっと面倒です。ルーティング設定中にActiveRecordを使うのはちょっと問題ありだし（Foodynで拡張している部分が読み込まれていないから）。

それをどこに置くかも含めてルーティング部分を大幅改造中。

スキン･エンジンの基本部分＋Rails Enginesのインストール

Sun, 4 Jan 2009 22:53:04 +0900

スキン･エンジンを独立したものにするときに問題になるところの一つが，Railsにおけるビューとコントローラの連携部分が使いにくくなることです。今回はいろいろ試行錯誤の末，スキン･オブジェクトを呼び出すときに，コントローラをインスタンス変数として保持できるようにしました。これでフォームの表示はできるようになりました。

次の問題はルーティング関係です。エンジンによって必要になる機能が違うため，共通のルーティングを使用するのはなかなか難しいところです。エンジンごとにルーティング指定できるといいのにと思っていたところ，Rails Enginesというプラグインにそういう機能があることが判明しました。とりあえずインストールして試してみます。

なかなか進みません

Sat, 3 Jan 2009 01:37:04 +0900

スキン周りは，スキン･エンジンの独立性を担保するため，インタフェースを大幅に制限しています。そのため，管理画面を作るところも不自由な面が出てしまうことはいなめません。ちょっと苦闘気味。

備忘メモ

Tue, 30 Dec 2008 22:55:27 +0900

スキンタイプに「css」を作る。スキン変数<%css%>で呼び出しできるようにする。

エラー処理を改善＆スキン･エンジンによる管理画面表示

Sun, 28 Dec 2008 03:44:24 +0900

権限チェックにひっかかったときの処理をどうするときれいになるか，ずっと悩んでいましたが，ちゃんとRailsが仕組みを用意していてくれたことが分かり，ようやくすっきりしました。

これまでは権限がないことが分かるとエラー画面を出力し，チェックルーチンの結果を判定してそこでコントローラを終了するかどうかを見ていました。つまり，

return unless check_sys_right :skin_management

といった形で必ず「return unless」を付けないといけなかったのです。これが汚いのでいやだったのですが，Railsではコントローラで例外が発生したとき，まとめて捕捉できる仕組みがあったので，それを使えばいいことが分かりました。これだと，チェックルーチンでは問題があったときに例外を投げます。それを捕捉ルーチンでチェックしてエラー画面を出力するだけになります。上述の「return unless」が不要になるので，コードがすっきりします。

このほか，スキン･エンジンを使った管理画面表示の仕組みの基本部分を作りました。例えば編集画面を出すときのコントローラの処理は次のようになります。




  def edit

    check_sys_right :skin_management

    @skin = Skins.obj(params[:id])

    

    @skin.edit

    render :file=>@skin.edit_page, :layout=>true

  end

ここで，Skinsというのはスキン･エンジンのとりまとめのクラスになっており，Skins.objメソッドで実際に処理を行うオブジェクトを取得します。@skin.editで編集に関連する下処理をしておき，つぎのrenderで表示します。@skin.edit_pageの部分はスキン･エンジンの抽象クラスで処理され，ここでそのスキン･エンジンと同じディレクトリにある「edit.html.erb」を呼び出します。子クラスでオーバライドすれば，別のファイルを使うこともできます。レイアウトを使うようになっているため，実際の表示部分ではHTMLの装飾部分は気にせずに作れます。これでスキン･エンジンに依存しない形でコントローラ側の実装ができました。

備忘メモ

Sat, 27 Dec 2008 03:18:25 +0900

Rubyで現在のスクリプトのファイル名は「__FILE__」で得られる。ただし，コンテキストは認識してくれない。親クラスで定義されたものを子クラスで実行しても親クラスのファイル名になる。

コントローラでのエラー処理はActionController::Rescueを使うとよい。これで権限チェックのところのコードがきれいになるはず。

RailsとMerbとの合併に思う

Fri, 26 Dec 2008 10:58:38 +0900

ここ数日，Rails界隈ではRails3がMerbベースになるというビッグ・ニュースでにぎわっています。これについては僕よりずっと詳しい人たちが，いろいろ書いていますので（参考1，参考2，参考3），今さら僕のような末端の開発者が論評を加えることもないわけですが，やっぱりすごいことだなあと思うので簡単に感想を。

僕がFoodyn CMSのプラットフォームとしてRailsを選んだのは，フレームワークのエコシステムという面を重視したのが大きな理由です。フレームワークはそれ自体の機能がいくらよくてもそれだけではだめで，その周りに多くの開発者が集まり，プラグインなどをどんどん開発していくことで価値が上がると考えています。

NucleusをPHPでフレームワークを使って書き直す話が出てきたとき，その第一候補になったのはSolarでした。Solarを開発している人はZend Frameworkの初期にも携わっており，優秀な人だろうと思います。また，Solarを推薦した人もその理由があってのことだと思います。いかんせん，あまりにマイナーであり，Railsのようなエコシステムができることは望めません。他のPHPのフレームワークを見ても，そういった求心力は欠けているような気がします。PHPではPearもなんだか中途半端だし，フレームワーク時代？における姿がよく見えないのです。

RubyでMerbが出てきたとき，すぐにRailsとの競争関係に入るとは思いませんでしたが，ばらばらな状況が生まれることは少し心配になりました。今回の合併は，そういった一抹の不安をかき消し，Railsの求心力を一層増していく効果があると思います。DHHを初めとする開発者の英断に感謝します。

正念場？

Mon, 22 Dec 2008 11:09:03 +0900

スキンの一覧表示はできるようになりました。問題は編集に移るところです。
スキン・エンジンに編集画面をどうやって出力させるか，できるだけヘルパーを用意して管理画面のデザインからの抽象化をしておかないといけません。結構大変そうなところです。

スキン管理に移る

Thu, 18 Dec 2008 10:21:31 +0900

アイテム（暫定），メンバー，ブログ，全体設定の管理画面が一応できたので，スキン管理に移ります。後は大きなところはプラグインとカテゴリー／タグ。12月中に一通り終わるのは厳しいなあ…

特にスキン管理のところは，複数エンジンに対応するため，スキン・エンジンとのインタフェースをどうするかがなかなか難しいです。