2007年5月アーカイブ
ご期待ください。
みんな大好き「○つの方法」的キャッチータイトルをパクるもこのエントリは流行らない･･･っ！
Piece_ORM を動作させるには、Piece_ORM クラスの configure メソッドを実行させることで動作環境を構築します。このメソッド実行には、３つのディレクトリを指定することになります。
実際にはPiece_ORM短期集中コースを読めば全て載っていることですが、この３つのディレクトリを簡単に理解するポイント、また使い始めてもふとやってしまう失敗ポイントをあわせてここでも紹介しておきます。
(1) configDirectory
設定ファイルを置いているディレクトリ。
一見とても重要な内容、というか事実そのとおりなのだが、実は指定するディレクトリに piece-orm-config.yaml という設定ファイルがあるかどうかというだけでしかありません。piece-orm-config.yaml は Piece_ORM を動作させるためのデータベース接続設定およびそれに付随するオプションを指定するためのファイルです。
(2) cacheDirectory
キャッシュデータが書き込まれるディレクトリ。
Piece_ORM はキャッシュデータ命というか、「キャッシュデータを作成」→「そのキャッシュを元に駆動する」という仕組みとなっています。「Piece_ORM が動作しない」というケースに出くわした場合、その原因は
・キャッシュディレクトリが存在しない
・プログラムがキャッシュディレクトリに書き込む権限がない
である可能性が高いでしょう。
(3) mapperConfigDirectory
データベーステーブルのマッパー定義ファイルが設置されているディレクトリ。マッパー定義ファイルはテーブルごとに存在します。
前述のキャッシュデータを作成するために、Piece_ORM で操作対象とするテーブルは全てファイルを準備する必要があります。「Piece_ORM が動作しない」理由は
・指定するテーブルのマッパー定義ファイルがない
という原因である可能性もあります。
この設定ファイルでは、任意のメソッドとそれに対応する任意の SQL クエリ、リレーションシップ定義を記述するようになっていますが、よく使われる汎用的なクエリメソッド (select, insert, update, delete) は定義することなく使用できます。
したがって簡単な動作を行う場合は設定ファイルを記述することはない、つまり 0 バイトのマッパー定義ファイルだけが存在することになります。
オージーで作ったら硬い。
関西セミナーや勉強会などに参加されていた方にはその場でちょこっとお話をしていましたが、このたびPHP情報のポータルサイトPHPプロ！上で短期的な連載を始めることになりました。
毎回何かしらの PEAR ライブラリを取り上げ、中身のコードを読みながらどのように実装しているかを紹介、解説していくという講座です。
私のイラストに対して「こんな爽やかじゃない」などという意見を事前に ITEMAN 他多数から頂いております。
なお立ち上げ当初内容を考えるフェーズで「くまっち総研」と題打ってひたすらネタを掲載する、という案を出したにも関わらず華麗にスルーされ現在の内容に決まったという経緯があったことをここに書き記しておきます。「まあ使えるけどマイナーPHP関数選手権」とか「stdClass さん vs __PHP_Incomplete_Class さん」とか「高田総統、PHP を使う」とか。
先週末は久々にBMM尊師と二人で、某店感謝祭による大量コース料理をたらふく食べてきました。
といっても尊師は結石の治療中だし私も大食いはすっかりご無沙汰で5年くらいブランクがある状態だったのでどうなることかと思ったんですが、まあほどほどに丁度よいボリュームでした。
・鯨の刺身
・デカアスパラ（茹で・焼き）
・ラム肉とアスパラの串焼き
・じゃが茹で
・寿司盛り
・ラム肉が入ったクリームシチュー
・ラム肉すき焼き（＋ラム肉追加）
・サラダ
・デザート
終わってからはファミレスで甘いもの食べながら休憩。
トイレの鏡で体を見てみたら、腹の部分だけヒョードルみたいになってました。
前エントリからの続きになります。
家庭用コントローラの中では突出してガチな作りをしているリアルアーケードプロ (通称 RAP) を分解してみてある程度パーツの扱いが分かったので、ジョイスティック部分やボタン部分のパーツを交換して遊んでみることにしました。
ジョイスティックレバーをセイミツ工業製に、ボタンを三和電子製に変更します。
この前の Piece 勉強会の懇親会後、急に私の家でゲーム会を開催することになったとき、アーケードゲーム用コントローラであるリアルアーケードプロ (通称 RAP) のボタンの１つが利かないことが判明。
ザンギエフで小パンチが使えないとか超きつい。
ということで分解して直してみることにしました。
あとで書く予定だったブツが、見つかってしまいました。
Piece FrameworkでFlexy派待望の出力オブジェクト切り替えが可能に？
いやあ、Flexy のこと全然分かってないので、こんな使い方できるのもこの前やっと知りました、サーセンｗｗｗ
とまあ半分冗談の半分本当なお話ですが、「実はこんなことができる」というのが続々登場する隠し技満載な HTML_Template_Flexy について、Piece_Unity のレンダラの拡張を提案中です。
さて、
3. ダミー要素にflexy:dynamic属性を付けておき、HTML_Template_Flexy_Elementのchildrenフィールドを使ってダミー要素の内容を書き換えるか、overrideフィールドを使ってダミー要素そのものを書き換える
これを行うには HTML_Template_Flexy_Element に対しての操作を実施することになるのですが、
1. アクションクラス内にまで HTML_Template_Flexy_Element クラスを持ってこれるようにし、それに対してユーザが任意に操作する (新規拡張案 A)
2. アクションクラス内にまで HTML_Template_Flexy_Element クラスに相当するような Piece_Unity 専用のクラスを持ってこれるようにし、それに対してユーザが任意に操作する (新規拡張案 B)
3. ViewElement に対して「決められたルールに従う」ような特別な値をセットしておくと、Flexy レンダラが HTML_Template_Flexy_Element に対しての操作をしてくれる (既存拡張案)
簡単なのは 3. で、現行のアクションクラス内で行っている Element 操作と同じような
$elements['foo']['_children'] = array('Bar', 'Baz')
$elements['hoge']['_override'] = 'Hige';
$viewElement = &$this->_payload->getViewElement();
$viewElement->setElement('_elements', $elements);
みたいに使えるようになる形なのですが、children には Flexy_Element オブジェクトも指定できるのでそれをどう実現するかという点と、現行のこの仕組みについて ITEMAN と「黒魔術的だねえ」という風に思っている点 (特に最終行の _elements) をどうするかですね。
しかし 1. レベルになると、アクションクラスに特定のレンダリング機構の操作が堂々と登場してしまうのも残念すぎるため避けたいところで、つまるお話、この「特定のレンダリング機構の匂い」をどこまで出してよいかというのを考えてから形にしたいところです。
そういう意味では今回要望に出した出力オブジェクトの切り替えとプラグインの使用についてはこれが見事クリアできていて、
* 「Renderer_Flexy の設定ポイント」による指定
* 利用者が必要に応じてのみ準備する別ファイル形式
という具合になっているため、仮に如何ともし難い理由によりテンプレートエンジンを変更する場合においても一切の影響が出ない（もちろん変更後のテンプレートを別途準備する必要はあります）という形式の拡張となってます。
まあ 3. 案については、children 内の配列内要素をリテラルに限定するならば比較的すぐにでも実装できそうではあります。あとは (使ったことない) prefix, suffix あたりも準備したいところですが、こちらも Flexy_Element である必要があるため難しい……仮に実装したとしても、今のままではさらに黒魔術的な操作になっちゃいそうです。
ちなみに、
Flexyには、Smartyが標準で用意しているカスタム関数 {html_checkboxes} や {html_radios} のような、要素のリストを出力する機能がなく、不便に感じることが多々あります。
YOU, 唯一準備されている Flexy_Plugin の Savant を使っちゃいなよ！
<!-- lists は array('foo', 'bar', 'baz') -->
<span flexy:foreach="lists,k,v">
{this.plugin(#checkbox#,k,v):h}{v}
</span>
{this.plugin(#radios#,#hoge#,lists):h}
続きは、Source で！
今回の要望が通ったら、これからはこういう操作も Piece で使えるようになります。
しかしこういう値の出力系をやるならやっぱり Smarty のほうがよいような気がせんでもないです。
更に、HawkさんのFlexySupportみたいなことができれば…。
「みたいなこと」は FormRenderer ですか？要は Form 値の自動適応。
まあ、ジワジワと Eclipse の練習も始めとるんです。
Emacs キーバインドのような設定内容を準備していただいているわけで、偉大なる Eclipse の先人者の方々には感謝しつつも、やっぱり違うのですよ。
変更するには、まずは以下を参照のこと。
ちなみにデフォルト内容のキーバインド設定と共存するような形になるので、明らかに重複しているような設定（たとえばコピーなんかは、M-w と C-c の両方がエントリされる）などは削除していくとよいかも。
上記にも以下を実施。まだこれでも全てじゃない予感。数が多くてチェックが大変。
・C-j も Enter に
C-M と同様、デフォルトがインクリメンタルサーチになってしまっているので、これを消去するとよい。
・C-/ を undo に
デフォルトではソースコメントの In/Out トグルになっているのでこれを「元に戻す」に設定する。ちなみに「やり直す」も別キーへ割り当てれるので、C-. あたりにしとくとよろしい。
ついでにトグルも好きなキーバインドへどうぞ。
・M-S-5 (M-%) を置換に
「検索と置換」に設定することで、専用のウィンドウが出せるようになる。
ちなみに正規表現置換も同じウィンドウで行うことになるので、C-M-S-5 (C-M-%) も一緒にバインドしとく。
・C-o を「現在行の下に行を挿入」に
実はこれ、厳密には Emacs と一緒の動きをしない。行を挿入すると共にカーソルも下に動いてしまうので極めて意味がない。
こういう「テキストエディタとしての機能」の挙動を変えたいときはどうすればよいのかなあ。
C-o のも変更したいし、C-Space でリージョン選択の開始が行いたい。Emacs 風キーバインドでも C-Space に割り当てられる「マークの開始」はリージョン選択の開始マーキングではないし。たとえばリージョン選択した対象に対してのコメント In/Out とかもサポートしてるのに、これでは片手落ちじゃないのかなあ。
エディット箇所のウィンドウに任意のエディタを埋め込めないですか。拡張子による外部エディタ登録ではなくて。
ご期待ください。
