2008年3月アーカイブ
前回のエントリの続きです。
前回からの進展としては、時間切れで出来なかった関数実行、指定する DOM Element の要素書き換えや、繰り返し処理の実装。そしてここまで来るとコードがさらにゴチャゴチャとしてくるので、若干のリファクタリング作業をば。
繰り返し処理は PHP の foreach ～ as みたいなのができるように、例えば次のようにテンプレート側で foreach , as 要素を準備しといて、
<table>
<tr>
<th>id</th>
<th>name</th>
<th>email</th>
</tr>
<tr foreach="persons" as="person">
<td key="person.id"></td>
<td key="person.name"></td>
<td key="person.email.pc"></td>
</tr>
</table>
persons 変数に配列を assign すれば、こんな感じに置換される。
<table>
<tr>
<th>id</th>
<th>name</th>
<th>email</th>
</tr>
<tr >
<td key="person.id">1</td>
<td key="person.name">foo</td>
<td key="person.email.pc">foo@example.com</td>
</tr><tr >
<td key="person.id">2</td>
<td key="person.name">bar</td>
<td key="person.email.pc">bar@example.com</td>
</tr>
</table>
一方、DOM Element の要素書き換えはテンプレート側の準備一切なしで PHP 側から Element指定＋内容適応。なお Element の指定方法はひとまず DOM パーサ仕様で。jquery like なものなのでスムーズに使えそう。
<?php $template = new Template(); $element = new stdClass(); $element->class = 'example'; $element->aaa = 'AAA'; /* id="foo" の Elememt に class="example", aaa="AAA" を追加 */$template->setElement('#foo', $element);$template->setAttribute('#foo', $element); /* メソッド名変更予定 */ $template->renderer('Example'); ?>
なお現在の仕様はこちら。
テンプレート変数割り当て - オブジェクトを割り当てると、プロパティがテンプレート変数として利用される - 連想配列を割り当てると、配列キーがテンプレート変数として利用される - テンプレート変数として配列が利用できる - テンプレート変数としてオブジェクトが利用できる - テンプレート変数は配列とオブジェクトが混合で利用できる - テンプレート変数として割り当てたクラスオブジェクトのメソッドが利用できる - テンプレート変数に対して関数が利用できる - タグ内のテンプレート変数の要素名が変更できる - 置換されるテンプレート変数は何もせずともhtmlspecialchars済み - 置換されるテンプレート変数のhtmlspecialcharsは個別で無効にできる - テンプレート内で同じ変数は、利用タグに関係なく何度でも使える - 値がassignされていないテンプレート変数は無視される エレメント操作 - セレクタによる指定ノードのエレメントが追加、変更できる - セレクタによる複数対象のエレメントが追加、変更できる - エレメントの各要素のうち、今のところタグ名は変えれない 繰り返し処理 - phpのforeach_as_valueのような処理ができる - phpのforeach_as_key_valueのような処理ができる - 通常の変数と繰り返し対象の展開変数の変数名が重複した場合は、展開変数が優先さ れる - 繰り返し対象の展開変数がオブジェクトや配列も利用できる - 繰り返し処理はネストできる 20 examples, 0 failures
実は前回の仕様ではテンプレートはキャッシュするようになってたんですが、その機構はひとまずカットしました。毎度テンプレートを DOM パースする必要はないなと思って準備してたんですが、PHPコード側から動的に値が適応される「Element 書き換え」を行う場合は結局毎回パースしなおさなければならず、その辺非常にややこしい処理になりそうだったので、現時点ではあまり深く考えなくてよいよう機構そのものをなくしました。
まあ Element 書き換えが発生しない場合も当然あるでしょうから、後々キャッシュできる機能とそうでない機能をきちんと分けた上で改めて再考すればいいかな。
あと、ちゃんとカッコイイ名前をつけたほうがよいとのことで、どうしたもんかと思っているわけです。ネタでいくならKumartyだな！
男なら一度はテンプレートエンジンの作成に挑戦してみるよね！
ということで PHP Simple HTML DOM Parser を使って、DOMパーサ利用ならではのテンプレートエンジンを作ってみました。
ひとまずはテンプレート変数の利用だけ。クラス名とかは考えるのが面倒だったのでひとまず Template で。
PHP
<?php
require_once 'Template.php';
$variables = new stdClass();
$variables->foo = 'AAA';
$variables->bar = array(1, 2);
$variables->baz->quux = 'BBB';
$template = new Template('./templates', './caches');
$template->assign($variables);
$template->renderer('Example');
?>
Template (Example.html)
<html> <head> </head> <body> <span key="foo">hoge</span> <div key="bar.0">hoge</div> <p key="bar.1">hoge</p> <p key="bar.2">hoge</p> <font color="#FF0000" key="baz.quux">hoge</font> </body> </html>
結果
<html> <head> </head> <body> <span key="foo">AAA</span> <div key="bar.0">1</div> <p key="bar.1">2</p> <p key="bar.2">hoge</p> <font color="#FF0000" key="baz.quux">BBB</font> </body> </html>
割り当てたオブジェクト（もしくは連想配列）のプロパティが、タグ内の「key=***」という属性で指定されている箇所をテンプレート変数として置換。変数としても配列、オブジェクトともに利用可能。あと「key」という属性名も好きな名称に指定可能。
PHPTALってよりmayaaに近い？（使ったことないのでよくわからない。中間層の XML もないけど。）
まだまだ途中段階だし、コードもベタに書いて一切見直ししていないのでアレな内容ですが。
ちなみにアーカイブ内の specs ディレクトリ内は、PHPSpecによるファイル群（スペック、テスト）で、ここを見れば＆動かせば、現在の仕様や利用方法などが分かります。
なお現在の状態はこんな感じ。
テンプレート変数割り当て - オブジェクトを割り当てると、プロパティがテンプレート変数として利用される - 連想配列を割り当てると、配列キーがテンプレート変数として利用される - テンプレート変数として配列が利用できる - テンプレート変数としてオブジェクトが利用できる - テンプレート変数は配列とオブジェクトが混合で利用できる - テンプレート変数として割り当てたクラスオブジェクトのメソッドが利用できる - テンプレート変数に対して関数が利用できる (ERROR) - タグ内のテンプレート変数の要素名が変更できる - 置換されるテンプレート変数は何もせずともhtmlspecialchars済み - 置換されるテンプレート変数のhtmlspecialcharsは個別で無効にできる - 置換されるテンプレート変数に対して個別にurlencodeできる - 置換されるテンプレート変数に対して個別にnl2brできる - テンプレート内で同じ変数は、利用タグに関係なく何度でも使える テンプレートエンジンの利用 - 利用するとキャッシュができる - キャッシュデータがあるとそれが描写で再利用される - キャッシュデータ作成後にテンプレートが更新されると、キャッシュを作り直して描写する - テンプレートファイルの拡張子が変更できる 17 examples, 0 failures, 1 error
関数利用を作ってる最中でタイムアップ。また後日にでも。
これ面白い。
require_once 'html_dom_parser.php';
$dom = file_get_dom('http://www.google.co.jp/search?q=%E3%83%94%E3%82%AB%E3%83%81%E3%83%A5%E3%82%A6&lr=lang_ja&ie=utf-8&oe=utf-8');
foreach ($dom->find('a') as $node) {
$node->innertext = str_replace('ピカチュウ', 'オプーナ', $node->innertext);
$node->href = 'http://www.opoona.com/index.htm';
}
foreach ($dom->find('b') as $node) {
$node->innertext = str_replace('ピカチュウ', 'オプーナ', $node->innertext);
}
print $dom->save();
なんか色々思いついたので、暫らくの間これで遊びます。
ごちゃーっとしていることに嫌気が差した2008年、思い立って自宅室内にところ狭しと並べられていた家電、パソコン類を整頓することにしました。
手始めに、既に使っていないくせに何故か部屋の中に留まり続けていた小型のブラウン管TVや CRT ディスプレイを処分。
驚くべきことに4台にもなっていた自作パソコンも、機能面や用途面を含めてえいやと一台に集約して残りを排除。
うちに遊びにきた人は必ず反応していた3面もの液晶ディスプレイも、ワイド24型を1つだけを残して残りは排除。
テレビに接続されていた各種プレイヤも、HDDレコーダ１つを残して残りは排除。
と、ここまで一気に進めて室内スッキリし始めたところで、PC からアナログ線で繋いで利用していた古いステレオアンプ＋スピーカーx2が何故か気に入らなくなり、デスクトップPC向けのエレガントな2.1chサラウンドシステムを IYH!（イヤッッホォォォオオォオウ！の意ですなわち衝動買い）。調整も済んでいい音を楽しんでますが、思い切りやってしまった感が。
家電はこんなところで、後日は本類に着手する予定。
Piece_ORM を使えば、だれでも簡単にデータベースを使ったPHPプログラムを書くことができます。（任天堂のCM風に。）
1. フォルダの作成
Piece_ORM を動作させるには、プログラムのファイルとは別に3つのフォルダを使います。
プログラムファイルを作成するフォルダ内に、次の3つのフォルダを作成します。
・config
・cache
・mappers
2. データベース情報を準備する
次に Piece_ORM から接続するデータベースサーバの情報を設定します。
仮にデータベースの情報が
データベース: PostgreSQL
ホスト名: localhost
database : example
username : example_user
password : example_password
以上のようなものなら、先ほど作ったフォルダのうちの１つ、config フォルダの中に「piece-orm-config.yaml」という名前のファイルを作成し、次のように記述します。
- name: database1 dsn: pgsql://example_user:example_password@localhost/example
3. テーブルを準備する
続いて、実際にプログラムから読み込みや書き込みを行おうとするテーブルを準備します。
データベース内の実際のテーブルは予め作成しておきます。ここでは「person」という名前のテーブルを作成したとします。
先ほど作ったフォルダのうちの１つ、mapper フォルダの中に「Person.yaml」という名前のファイルを作成します。中身は何も必要ありません。
4. プログラムを書く
最後にプログラムを書きます。書くプログラムは非常に短くて簡単です。
SELECT 文の SQL は次のようなコードを準備します。SELECT した結果のレコードがオブジェクトとして簡単に参照が可能です。
<?php
// Piece_ORM を読み込む
require_once 'Piece/ORM.php';
// Piece_ORM を設定する
Piece_ORM::configure('config', 'cache', 'mappers');
// person テーブルを対象にする
$mapper = Piece_ORM::getMapper('Person');
// select * from peron where id = 1;
$person1 = $mapper->findById(1);
echo $person1->name; // name カラムを表示
// select * from peron where name = 'foo';
$person2 = $mapper->findByName('foo');
echo $person2->name;
?>
INSERT, UPDATE, DELETE も簡単です。
<?php
// Piece_ORM を読み込みと設定
require_once 'Piece/ORM.php';
Piece_ORM::configure('config', 'cache', 'mappers');
// person テーブルを対象にする
$mapper = Piece_ORM::getMapper('Person');
// 新しいレコードとして INSERT
$person = new stdClass();
$person->name = 'foo';
$mapper->insert($person);
// name カラムを変更して UPDATE
$person->name = 'bar';
$mapper->update($person);
// DELETE
$mapper->delete($person);
?>
音楽や動画などのデータを保存しているストレージ用のマシンとHDDがヘタれたので、ひとまず新しいHDDを買ってきたんですよ。この手のPCパーツを買うのは2年ぶりほどですけど、相変わらず暫らく遠ざかっているだけで性能アップと価格ダウンの進展が大きくて驚くばかりですよ。HITACHI の省電力仕様のHDD 500GB が 9000円でした。
で、タイトルにあるように iTunes ライブラリ（音楽データ、アートワーク、楽曲再生リスト）を新しい HDD に移しつつ、既存の再生環境でも正しく再生されるようにしないといけないなあと思ったんですね。気をつけないと「データが見つかりません」とか言われてデッドリンクが大量発生しちゃうし。
そこで、ふと気づいたんですよ。なんで今までこの方法が思いつかなかったんだろうと。google で調べても同じことやってるケースが一杯ヒットしているくらいだし。
iTunes ライブラリ用って１つのフォルダにまとめられているんで、そこをシンボリックリンクにすれば、参照先がどこに移動したって再生環境側は気にする必要がないんですよね。仮に再生側で再インストールしたとしても、ストレージ側の iTunes ライブラリをシンボリックリンクしなおせばすぐ元通りだし、今回のようにストレージ側が変わっても、これまた同じようにシンボリックリンクしなおせばすぐ参照できるようになる。
まずは現行の再生側の iTunes ライブラリフォルダをバックアップなどに移して、iTunes から認識できるライブラリフォルダが存在しないようにしときます。Windows ならば「マイミュージック」内に iTunes がない状態に。一方、実際の iTunes ライブラリフォルダがどこか別のところにある状態にします。ここでは仮に d:\music\iTunes あたりとします。
Windows 環境では通常シンボリックリンクをはる手段がないものの、MS の TechNet でシンボリックリンクを作る junction コマンドのプログラムが配布されているようなのでコレを使うとOK。windows フォルダや system32 フォルダあたりの実行パスが通っているところにコピーしたあと、コマンドプロンプトを立ち上げて以下のように junction コマンドを発行してあげればOK。
c:\Documnets and Setting\username\My Documnets\My Music > junction iTunes d:\music\iTunes
ちなみに Cygwin 環境があれば ln コマンドで同じことができます。
これで、見かけ上はマイミュージックに iTunes フォルダがあるように見えるものの、実際その中身は d:\music\iTunes という状況に。
再生側は全般的に c:\Documnets and Setting\username\My Documnets\My Music\iTunes として見えているので、これのシンボリックリンク先がネットワーク越しの異なるマシンなんてこともOKでしょう。複数マシンが1つの iTunes ライブラリを参照する状態になるので、どのマシンでもライブラリへの楽曲追加ができるし、共通の再生リストも利用できますね。
