CodeIgniterにJobboardを組み込む3-Another Codeigniter CMS (ci-cms)を軽く動かして拡張箇所を想像してみる-その2（良い点悪い点微妙な点）
こんにちは！
今日はCI-CMSの良い点・悪い点（微妙な点）を挙げていきます。
前回エントリーの画面ダンプのおまけの内容とあまり変わらないかも。
これをベースに魔改造して、使えるモノが出来るかな？
という視点で以下ずらずら感想をば。
良い点：
良い点1：モジュール機構がxoopsライクに、MatchBoxのモジュール設置→インストール→アクティべートを経て使う仕組みである。上手にMatchBoxを使って、モジュールのインストールの仕組み・更新の仕組み・管理の仕組みを構築している。これだけでも、これをベースにモジュールを作ろうかな？という気になります。
モジュール機構（インストール・アクティベート）を作るところから始めるのはしんどいので、これは助かります。
モジュール管理の仕組みを自力で作ろうとすると、
■インストーラー
- DBにテーブル作成
- マスタデータ挿入
- 有効無効の仕組み
■アップデーター
- DBのテーブル定義更新
- マスタデータ挿入・更新
■モジュール毎のURLルーティング
■モジュール毎の専用ファンクション（プラグイン的なもの）
■モジュール毎の言語ファイル
■モジュール毎の管理画面
等々基本の表側の動き以外に考えることが沢山あるのですが、
既にモジュール管理の仕組みが出来ているので、
ソース量の少ない手頃なモジュール（newsとかsearchとかのモジュール）を解析して
そのやり方にならって、モジュールを作っていけば良いと思います。
仕組みが分かってしまえば、ディレクトリ丸ごと複製→ソースコピペレベルから試し始められるのでこれは楽。
Xoopsのモジュールの仕組みや、Drupalのモジュールの仕組みを読み解くのに苦労した人ならば、
CodeIgniterの楽さが分かると思います。
フレームワークのベースの仕組みを理解しモジュールを作るところまでに到達するのが大変だと、
その時点でやる気をなくす＋工数に含まれない調査工数が必要になってしまう＋作る人が決まらないのに機能構成表と工数計算ばかりやり直して、資料が出来たらなんとなく仕事が終わった気になる。
といった羽目に陥りがちなのですが、CIならばこれを避けることができます。たぶん。
ちなみにCakePHPは覚えるのが嫌い＆勉強のための勉強が嫌い＆既存ソースとのキメラ化が大好きな私の性に合いませんでした。CodeIgniterは分からなかったらすぐ該当ソースを直感で探せて弄って改造できる構成だと思います。
大人数での開発は知りません。そもそもPHPで大人数で作る時点で半分間違って(ry
（モジュール管理の図）
良い点2：モジュール毎の権限設定が出来る（っぽい）
用途によっては微妙な点（そこまでは不要な点）にも含まれるのですが、登録ユーザー毎＆モジュール毎に権限設定が出来ます。
アクセス不可・閲覧・追加・編集・削除のレベルを設定出来るようです。
複数の管理者（スタッフ）にCMSの管理をさせる時に使い道がありそう。
例えば、今回のエントリーの様に求人情報モジュールを新設すると仮定して、
- 表側のコンテンツ作成担当者＝ホームページ担当
- 求人情報モジュール上で求人データ登録を行う人間＝データ入力担当
- 求人情報モジュール上に貯め込まれた応募データを取り扱う人間＝業務担当
毎にレベル設定をするとか。
（モジュール毎・ユーザ毎権限設定の一覧）
（権限設定画面）
良い点3：デフォルトで多言語対応が出来る
多言語対応（複数言語＋複数言語毎に別コンテンツの作成）が出来ます。
後でさわりだけ書きますが、
英語版 http://example.com/home や http://example.com/about 等のページと、
日本語版 http://example.com/home や http://example.com/about 等のページを、
完全に別物として作成出来ます。（URLは一緒）
また、管理画面（バックエンド）側のナビゲーション管理メニューや、ページ管理メニューも、言語毎に管理が分かれます。
日本語だろうが、英語だろうが、フランス語だろうが
http://example.com/home
http://example.com/policy
http://example.com/hogehoge
がデフォルトで使えるのはなかなか良いかな。（使用言語は閲覧者毎に切り替え可能）
ちなみに下の画面ダンプでは、日本語化の翻訳を行わずにpoファイル（後述）を使い回している＆英語版ページにも日本語文章を記述しているので何が違うのか分かりにくいと思いますが、そのへんは脳内で補完してください。
（多言語対応のテスト例）
1e:英語版ホームページ：（といいつつ日本語書いているけど）
1j:日本語版ホームページ：英語版と中身・写真が違う
2e:英語版aboutページ：
2j:日本語版aboutページ：
3e:英語版ナビゲーション管理画面：（英語版はメニュー多め）
3j:日本語版ナビゲーション管理画面：（日本語版はメニュー少なめ）
4e:英語版ページ管理画面：（英語版はページ多め）
4j:日本語版ページ管理画面：（日本語版はページ少なめ）
良い点4：サインアップ・ユーザー管理のベースソースがある
良い点2と被りますが、ベースソースがあってほぼ出来上がっているので、改造は楽でしょう。
以前のエントリーで挙げたdx_authを使って作る手もありますが、既に全体像が出来上がっているので、
ci-cmsの仕組みをそのまま使った方が楽。
良い点5：ajax(jquery)での画像アップロード処理のソースが既にある。
調べるのが面倒なので流用してしまいましょう。jqueryのサンプルになりそうなソースもあるので、楽かな。
ちなみに私はxajax中心でゴリゴリやってきたクチなのでjqueryはサワリ程度しか知りません。
良い点6：tinymceが既に使える状態にある
これも調べるのが面倒なので流用してしまいましょう。
流用ばっかりですねｗ。実現したい事を最短で実現できるので良しとしましょう。
（成果を一部でもコミットできれば良いかなと思いますが、まずは一連の仕組みを手元に引き寄せるところから。）
良い点は他にもありそうですが、疲れたのでこのくらいで。
また気づいたらその都度書きます。
悪い点（微妙な点）
書いていて飽きてきたので列挙のみ１）モジュール機構がHMVCベースじゃなくてMatchBox
HMVCをこれまで使ってたので慣れていない。
２）多言語構成には、ja.poファイル等poファイルを作らないといけない。
多言語対応には、modules/hoge/locale/ja.po とか、 modules/hoge/locale/fr.po とかが必要になります。
多言語対応するところは、
<?=__("Text to search", "search")?>
みたいな感じで書くとxxx.poファイルから翻訳したテキストを表示してくれます。
poファイルの編集には、Poeditを使います。vimのプラグインとかもあったっけ？
CI標準のlanguage/japanese/hoge_lang.phpじゃないのがちょっと気に入らないです。
（ MMRT daily lifeさんのPoedit 取扱説明書 http://wp.mmrt-jp.net/plugin-japanization-project/poedit/ 等を参照）
３）テーマは自作か他から移植しないと微妙にダサイ
タダで使わせてもらってダサイゆーなって気もしますが、
デフォルトだと微妙なのでどうにかしないといけません。
今回は、MOONGIFTさんの所で紹介されていた「Web App Theme」をベースに使ってみようと思います。
http://www.moongift.jp/2009/06/web_app_theme/
http://github.com/pilu/web-app-theme/tree/master
こんなのや
こんなの
すっきりしていて改造しやすそうで良い感じ。
４）これまでの俺俺ソースと融合するマージ作業が面倒
これは仕方がありません。基本的にファイルコピーレベルで済むと思いますが（多分８割方それでＯＫ）、WinMergeで目視確認しながらしこしこ移植していきます。過去の資産は使わなきゃね。
懸念事項としてはjquery周りか。確かxajax(prototype.js)と共存させるときにはおまじないが必要だったような記憶が。
５）日本語翻訳ファイルが無い
ja.poファイルを作って翻訳していく必要があります。
ただ、多言語対応がそもそも必要なければ、新規作成モジュールに関してはべた書きでいいかも。
海外に進出する要件でもないのに多言語対応する意味がありません。
必要になった時に急いでやれば良いだけ。
多分ならないので、時間を使ってまで流儀に従うこともないかと。
無駄な儀式は省略していきましょう。
良い点で挙げた通り、仕組み上は多言語対応出来ているので、
後回しにしていても後で手を入れる箇所は少なくて済むでしょう。
同様のことはモジュールのインストーラーのDDL文にも言えるかも。
６）ci-cmsのバージョンがまだ0.9
今回は開発のベースにするだけで別物になるので気にしませんが、気になる人はなるかな。
７）携帯対応しなくちゃいけない
こればかりはしょうがないですね。なんとかしないと。
携帯サイトなんてものがが無くなれば一番いいのですが。
てゆーか、Cookieが使えるようになればいいのだけど。
Cookie不可だのRFC違反のメアドだのバリバリ独自仕様なのが開発者にとって邪魔です。
というわけで今回はここまで。
次回からは開発中に書き留めたメモ等をだらだらと挙げていく予定です。
twitterボットもボットレベルに進化させたいのですがそちらも追々書いていきます。
ではでは！
