2005年11月アーカイブ
maple 3.0.3 以降の話が、kunit さんから具体的に出されてます。
Generate だけでなく、template 部として FlexyView も！ということになりそうな感じかな。こうなると ViewSimple もあるとバラエティに飛ぶし、現行の Smarty4Maple も埋め込み型ではなくきっちりと plugin 型に作っておいたほうがいいでしょうね。
現在命名法がバラバラなので、きっちり揃えるのがいいかもしれないですね。もしくは、
View.class.php
View/Simple.class.php
View/Smarty.class.php
View/Flexy.class.php
という形のように、ここらで一丁形式を固めてしまうのも手。以後革命的な template が登場したとしても、View ディレクトリ下にその template 向け plugin をおくようにすればいい。
component についても、名称をキモくない形 (w にという話が。
PEAR コーディング規約に準拠したものへ、とのことですが、わたしゃ別にそこまでガッチリ限定する必要ないと思うのですよ。ただし推奨はする。実際私も PEAR コーディング規約に従っています。次リリースは core, filter 群のタブインデントは半角スペース x4 にすべき！
たとえばクラスに関して、PEAR コーディング規約ではクラス名は各階層レベルの文字を含むものとし、またそれぞれの先頭文字は大文字にすべきとある。もちろん推奨レベル。PEAR の中でそれ前提で構えているコードは今のところ見たことがない。
maple で component を読む際に、現在では ucfirst() したりとかしている箇所があるのですが、もし component 体系を変更するのであれば、これらの処理もあわせて除外するほうがいいと思います。つまり DI ファイルで記述されている大文字小文字にすべて従う。自動的に変換することはしない。hoge とか書かれているけど、本当は Hoge なんじゃない？とかいうような処理は、利用者にとっては本当はいらぬお世話なのかもしれません。
以上を盛り込む前提としてこれを 3.0.3 内容としてざっと考えてみると、変更内容がクリティカルすぎるような気もします。3.0.2 向けのコードも許容するような case, if 処理も盛り込むくらいなら、いっそのこと 3.1.0 としてリリースしちゃってはどうでしょうか？
もちろん「下位互換ありません！」宣言をした上で、3.0 系からの移行をする場合に変更しなければならない点をあげる。今なら component ファイル名の変更、View 部分の指定くらいでしょうか？要変更だけどそこまで大変な内容じゃないし、道筋を立てておけば大丈夫だと思います。
Iteman が小規模ながらも超特急で Web アプリ組む必要があるってんで、maple を使ってペアプロ (Driver が Iteman) をやったんですが、その時思ったのが、やっぱり「はじめての maple」 をするのは難しいってこと。
「ここでの名称はこうでないといけない」
「こういうのを準備しなければならない」
というのが、maple の特徴のひとつである DI を使用しないシチュエーションですでに登場するのが後ろで見ていてまじまじと分かった。maple を使い始めてまもなく1年になる私は、その扱ってきた数、経験より「あれやって、これやって…」というのが流れ作業的にポンポン行うことができ、結果として人より早い速度で Web アプリを作り上げることができるのだけれども、いざこれから始めるという人にはやっぱり少々難しいと感じた。今ならサンプルありきでそこからの改変からスタートするのがベストなのだろうけど (実際私もすべてはそこから始まった。)
ドキュメント作成にあたり丁度 generate が具体化しつつある。重要なのは、「○○しなければならない規約」を自動生成して、使用者に規約を意識しなくてもある程度のことはできるということじゃないかなと思います。
最後に Iteman 先生の有り難いお言葉。
もう思いくそ既出だけれども、使用する component の実ファイル名がキモイとのこと。DI で[hoge:foo.bar.hoge] と宣言したのであれば、foo/bar/Hoge.class.php じゃなければいけないと。（現在は foo/bar/Foo_Bar_Hoge.class.php）
やっぱり DI ファイルには、名前、場所、クラス名の３点が記述できないといけないということかな。確かに、実際 DI につめるコンポーネントは maple で使用すること前提で準備されているとは限らない。
もし今後 generate でビジネスロジックの雛型が生成できるとしても、このあたりクリアになってたほうがいいなあ。
ある select SQL 文があって、その実行結果の件数だけを知りたい場合、例えば PHP ならば各 DB 毎に *_num_rows という関数があるのだけれども、実際得られる結果は「すべての結果が出た後に件数を全件舐めて出す」のか「非同期で実行するので件数に信憑性がない」のかよくわからない。前者なら全ての結果を得て、その件数を count していることと何ら変わりない。件数が少なければいいんだけど、多くなると多分凄いことになる。
そもそも偉大なる DBI の本によると、rows() メソッドの項に「ぶっちゃけ怪しいから count(*) しろ」と書いてある。つまり件数だけを知りたいならちゃんと count(*) SQL 文で件数を得た方がよいのだ。
さて、そんなシチュエーションにぶち当たってしまった本日。既に SQL 文は存在している。その SQL の件数だけを知りたい。でも count(*) SQL 文は用意できない。そんな場合どうやって count(*) SQL 文に変えたらいいのかなと思っていて引っ張り出してきたのが掲題のパッケージ、SQL_Parser。どうも perl の SQL::Statement からの参照らしい。
要は、SQL 文を一度 Parse して、select column の部分を count(*) に書き換えてしまえばいいというお話。こんな感じ。
<?php
require_once('SQL/Parser.php');
require_once('SQL/Compiler.php');
$sql = '
SELECT
id, name
FROM
member
';
$parser = new SQL_Parser();
$parseTree = $parser->parse($sql);
var_dump($parseTree);
$compiler = new SQL_Compiler();
$parseTree['column_names'] = array('count(*)');
var_dump($compiler->compile($parseTree));
?>
結果
array(7) {
["command"]=>
string(6) "select"
["column_tables"]=>
array(2) {
[0]=>
string(0) ""
[1]=>
string(0) ""
}
["column_names"]=>
array(2) {
[0]=>
string(2) "id"
[1]=>
string(4) "name"
}
["column_aliases"]=>
array(2) {
[0]=>
string(0) ""
[1]=>
string(0) ""
}
["table_names"]=>
array(1) {
[0]=>
string(6) "member"
}
["table_aliases"]=>
array(1) {
[0]=>
string(0) ""
}
["table_join_clause"]=>
array(1) {
[0]=>
string(0) ""
}
}
string(27) "select count(*) from member"
目的の個所を書き換えるメソッドが実装されていないのが何ともだけれども、とりあえずはこんな感じで使えそう。
ちなみに実際の SQL 文は JOIN, WHERE 込みの SQL だったけど、問題なく元通りに。なかなか面白い。
ダーク・エイジ・オブ・キャメロット第四回ゲームイベント
全レルムで一番強く面白い戦士は誰なのか？
ちゅーわけで第4回目となる3国共通イベント、参加してきました。
対人戦が売りな DAoC ですが、実は対人戦のイベントってのは初めて。
特別無料プレイ期間中に開催されたこのイベント、舞台は Lv.1-4 です。
毒殺未遂高校生の素顔とか DQN ドキュメンタリとかどうでもいいから PRIDE 放送しろよ糞関西テレビ。
