IEのoverflow: はちっともちゃんと実装されていない

PIGSには、カバーという概念があり、
コンテンツをカバーでラップすることで見栄えを変更したり、
ウインドウのようにマウスでドラッグしたりできるようになります。
カバーには不透明度の設定も可能です。

ただし、IEではある条件が重なった場合に、バグが発現します。

条件1. ウインドウのように浮遊させる。
　　　つまり position: absolute; width: ??px を設定する。
条件2. style.filter を使用する。
条件3. top: -10px; left: -10px のようにマイナスのオフセット値を指定する。
条件4. はみ出した部分をクリッピングしないようにする。
　　　つまり overflow: visible 又は auto を指定する。

といった条件下で、IEでは表示内容がクリッピングされてしまい、
カバーが身切れます。


表示されるべきものが、クリッピングされてしまっています。

IEの独自拡張であるフィルターの効果は、
原点(0,0)から要素の幅/高さまでにしか反映されないため、
それ以外の、はみ出る領域はoverflowの指定を無視し、
全てクリッピングされてしまうようです。

フィルターを使わない場合は、
overflow: visible; で勝手にボックスサイズを中身のサイズに合わせて拡張するくせに、フィルターを有効にすると、ボックスサイズの拡張どころか、overflowの指定を無視して、何が何でも切り取ってしまうようですね。


以下のようにfilter適用後のタイミングで、
強制的にoverflowを指定しても無駄なようです。

e.style.filter = 'alpha(opacity=' + 不透明度 + ')';
e.filters.alpha.opacity = 不透明度;
e.style.overflow = 'visible';

# overflow-x とか overflow-y とかも無駄。

Firefox1.5でvenkman + DOMイベント周りが仕様変更の模様

祝Firefox1.5リリース!
速い! 軽い! SVG標準サポート!
しか～し、最新のVenkmanはFirefox1.5で動かず orz

日本語版Firefox1.5配布FTPサイト

Live HTTP Headersは、サイト上に設置されたxpiをクリックで手動アップデート。
VenkmanはここからFirefox1.5用にハックしたxpiをクリックで手動アップデートすると動くぞ。と。

Firefox1.0.0と比べて劇的にレンダリングが速くなってます。
ちょっと感動しました。

ただ、JavaScriptのDOMイベント周りの挙動が、1.5と1.0.0では異なるようです。

画像のように、＜div style="overflow:auto"＞...＜/div＞な要素にスクロールバーが表示されていた場合に、スクロールバー上でonmusedownイベントが発生すると、
1.0.0では、explicitOriginalTarget.tagName に 'scrollbar'(全て小文字) が返ってきていましたが、
1.5では 'DIV'(全て大文字)が返ってきます。

tagNameって大体大文字なので、Firefox1.0.0の'scrollbar'の値が場当たり的な実装だったのかもしれませんが、
とにかくそういうことらしいです。

ユーザがスクロールバーをクリックした場合は、
ウインドウのドラッグ移動を開始させたくないので、

if(explicitOriginalTarget.tagName.toUpperCase() == 'SCROLLBAR')
{
　// ドラッグ拒否
}
if(explicitOriginalTarget.tagName.toUpperCase() == 'DIV')
{
　// ドラッグ許可
}

とかやっているコードは見直しが必要になってしまいました。

PHP5.1.0を入れてみる

風邪で数日へばっていたので、気分直しにPHP5.1.0をインスコ。
といっても、実施した作業は、

1. windows版のバイナリをダウンロード
2. 現在使用中のPHP5.0.3のディレクトリと解凍後のそれを丸ごと入れ替え
3. php.ini-recommended を、%windir%/php.ini として上書き
4. 以下の拡張モジュールの設定を php.iniに追加
　　extension=php_mbstring.dll
　　extension=php_mysqli.dll
　　extension=php_curl.dll
　　extension=php_gd2.dll
5. Apacheのリスタート

パス関係は通してあるので、インストールは5分でおしまい。

---

問題はここから。

PIGS0.3.0のコンテンツを表示させると、
Strict Standards: Only variables should be assigned by reference in ...と
Strict Standards: Only variables should be passed by reference in ... が予想通り、いくつか出てきます。
PHP4.4.0とPHP5.0.5でリファレンス(参照)の言語仕様が変更になったため、のようなんで、
function &xxxx() { return new class_db_MySQL(); }
な感じのコードを
function &xxxx() { $rv =& new class_db_MySQL(); return $rv; }
な感じに変更して回避。

んで、
Strict Standards: mktime() ...
は、タイムゾーンのサポートが追加されたために表示されるようなんで、
php.ini に
date.timezone = "Asia/Tokyo"
を設定し、Apacheリスタート

体感速度的には、PHPのパフォーマンス向上は感じられませんでしたが、
PIGSのコンテンツ生成速度が、
0.01秒ほど速くなった気がしないでもないという結果に収まったので、まぁよかったかなと。
PHP5.1.0では、ダイジェスト認証が標準で使えるようになっているはずなので、
前もって組み込んでおいた機能をやっとテストできます。

明日は、MySQL4.1を5.0にアップグレードして、
PIGSのドキュメント(前提環境)を、
PHP5.1.0 + MySQL5.0に直せば、ぼちぼちリリースですかね。Ver0.3.0も。

続: Google Maps + Google Analytics な mod_googleを追加

一晩放置してみたら、表示が

データの待機中: {Webサイト名}
Analytics を正常にインストールし、データの収集を開始しました。 最初のレポートは 12 時間以内に表示できます。

に変化していました。

最初に提示された記入例

＜script src＝"http://www.google-analytics.com/urchin.js" type＝"text/javascript"＞
＜/script＞
＜script type＝"text/javascript"＞
_uacct ＝ "xx-xxxxxx-x";
urchinTracker();
＜/script＞

を自由にイジって埋め込んでも、問題なく認識されることが確認できました。

さて、PIGSのリリースももうそろそろですか。

Google Maps + Google Analytics な mod_googleを追加

本当に忙しい時は、ブログを書く暇がないほど無口になってしまうということで。

今日は、Google Analytics(Googleのアクセス解析) ってのをYahooで見かけたので、
アカウントを取得し、
Google Maps + Google Analytics なモジュール mod_googleを追加してみました。

だがしかし、アカウント + スクリプト埋め込み完了から、1時間ほど経過しても

ウェブ サイトのトラッキングの確認が完了していません: ........
ウェブ サイトのホームページにトラッキング コードが正しく追加されているかどうかを確認するには、[ステータスを確認] をクリックします。 [ステータスを確認] をクリックすると、ウェブ サイトにトラッキング コードを追加する手順も確認できます。

と、そっけないメッセージが表示されてしまいます。

実際、Apacheのアクセスログ見ても、Google様は来てくれていませんね～。

さーて、何でだろうね。
サービス開始初日 + Yahooのニュースに載っちゃったから、
登録処理が集中したためなんだろうかね。

例によって、１日ぐらい放置してみます。

フックとかコールバックとか

PIGSの語彙の変更

モジュールに実装されたコンテンツ作成メソッドを表す適当な言葉が見つからずに、困っていましたが、
二年ぐらいに購入して積読してあった「Apacheモジュールプログラミングガイド」に良い用語がありましたので、
PIGSでも、モジュールが実装するコンテンツ生成メソッドのことを、Apacheに倣いコンテンツハンドラと名称を変更することにしました。
# Apacheモジュールプログラミングガイド 著者の小山さんも、私と同じ岩手出身で、ほぼ同年代なんですね。

PIGSにおける、モジュールとコンテンツハンドラの関係を、再定義すると…

PIGSはモジュールを動的にインストールすることができる。

モジュールは、コンテンツを生成するコンテンツハンドラと、管理画面(コントロールパネル)を好きな数だけ持つことができる。

コンテンツハンドラは、文字列を返すメソッドで、各モジュールのクラス内(モジュール名.php)に実装され、システムから自動的に呼ばれる。

管理画面は、管理画面専用のクラス(モジュール名 + cp + 管理画面のページ数.php)に実装され、システムから自動的に呼ばれる。

コンテンツの中に、独自の記法 (!mod_name:handler!) を埋め込むと、その部分は、コンテンツハンドラの出力に置換される。
# つまりコンテンツハンドラが動的に生成する出力をコンテンツ中に埋め込むことが出来る。

モジュールと、コンテンツハンドラの呼び出しタイミング。

HTML生成処理のある段階で、(!mod_name:hadler!) が見つかると、PIGSが必要なモジュールのインスタンスを生成する。

この時点でインスタンス化されていないモジュールはオンデマンドロードが行われる。

続けてモジュールに実装されているコンテンツハンドラが、各モジュールのevent()メソッドを通じて呼び出される。
より具体的には、コンテンツハンドラの呼び出しは、ユニキャストイベント(UE_CREATE_DYNAMIC_CONTENTS) の発行で行われる。
# PIGSからモジュールに対する指示は、ブロードキャスト/ユニキャスト・イベントシステムによる情報交換により行われる。

イベントを受け取ったモジュールはコンテンツ(又は空文字列)を生成し戻り値として返すことで、動的に生成した文字列(コンテンツ)がHTMLに埋め込まれる。

イベントのデフォルトハンドラが mod_base クラスに実装されているので、
イベント発生時には、モジュール名::ハンドラ(イベント引数) メソッドが通常呼び出される。
# この部分は、UE_CREATE_DYNAMIC_CONTENTSに対するイベントハンドラを定義することで、挙動は簡単に変更することができる。

コンテンツハンドラは、通常システム側から呼ばれるが、イベントシステムを通じて、
モジュールが他のモジュールのコンテンツハンドラを呼び出すことも可能である。

同様のイベントシステムを他のCMSでは「フック」と呼ぶらしいが…

フックという用語は、あくまでイリーガルな(アドホック)な挙動を実現するために非常時的に用意されているI/Fを叩き、
システムの処理に割り込んだり、入出力を横取り可能なOSのサービスの一つだと思っているので、
通常動作でバンバン発生するこまごまとしたコールバックの類を、フックと大仰な名前を付けるのは個人的には抵抗がある。

特にDrupalなどはこの傾向が強く見られ、Drupalでのモジュールの実装とはフックを実装すること、といった投稿もあるようだが

明日の6:00に起こしてよ とか 電話があったら取り次いでよといった、ホテルのフロントへの *お願い* を表現する言葉は、
モーニングコールやコールバックであり、
イベントが発生するたびに、ムリムリとワイヤーロープで引っ張られるイメージではないと思うんだが。

# 一般人に、「フック」といったら、そりゃフック船長のイメージが強いわけで…

php_strip_whitespace()でセグフォル

PHPコードから改行やコメントをストリップする便利なAPI
php_strip_whitespace() というのがあるんですが、
アクセスバイオレーション/セグフォルで落ちるんですよ、これが。

短めのソースコードだと何事もないが、
50kBぐらいのコードだと、ほぼ50%の確立で発生。

報告されるメモリアドレスもマチマチだし、
メモリの使用状況によって、落ちたり落ちなかったりするわけで、
zend_strip() 辺りにでもバグがあるんだろうが、
発生条件が確定できないので、バグレポートもやりづらい。

問題のコードは文法チェック的にも、
%> php -l xxx.php
%> No syntax errors detected in xxx.php といわれるんで無問題っぽいんですが。


ソースからデバッグ版をビルドして、追っかける気力というか、
ただでさえ足りない睡眠時間削るのはちょっと。

こちらでは、Windows2000 + PHP5.0.3で発生していますが、
PHP5.0.1～5.0.5のソースを追っかけたら全部同じ実装に見えたので、
PHP5全般で発生する気がする。

まぁ、php_strip_whitespace() ってのは代替が効かないメソッドではないわけですし、
php_strip_whitespace() 自体が歴史の無いAPIなので、
今後に期待。

PHPでオブジェクト指向を多用すると何かが犠牲に

はい。今日もPIGSネタです。

オブジェクト指向言語での常識をPHPに持ち込み、
真面目に書けば書くほど遅くなっちゃうみたいなんで、最近実装方法を考え直しました。


作業中のVer0.3.0の実装ポリシーは、
「高速性 >>> 単純なコード >>> 超えられない壁 >>> 将来的な機能への備え」です。

Ver0.2.0までは、
「高速性 >>> オブジェクト指向 + 将来的な備え >>> 単純なコード」でした。

どうも PHPにオブジェクト指向(OOP)を導入すると 遅くなる らしく、
速度的には両立しないどころか、諸刃の剣のようです。

将来性を考慮して
「コイツは、ファクトリで組んでおけば、バリエーションを作って差替え可能だね。」
「こいつはアイツにぐるぐる回してもらうとするか…」
なーんて事をウキウキ? しながらやってると、気が付けば、クラスまみれになります罠。

クラスが増えるということで、継承関係の解決やら、
クラスファイルの読み込みやらで、PHPのお仕事が大盛UP ⇒ 遅いということらしい。

別にデザパタを導入したからってそんなに複雑にはならないし、むしろ利便性アップなんだけど、
なんも考えずに、全てソレ式でやってしまうとダメみたいです。

Ver0.2.0を分解してこさえたVer0.3.0では、
通常実行されるコードの80%(Webページを生成する処理)を、ほぼ一本道(べた～っと)に書き直しましたので、
初心者には、処理の流れが追いやすい ⇒ 見やすいコードになっているかと。
# OOPに慣れた人には逆に新鮮(初心者が書いたコード)に見えるだろうが。

あまり欲張って将来のことを気にせずに、適度に最適化したコードを最初から実装するのが吉かと。
# 実装が一種類しかないのに、ファクトリを導入すると遅くなるだけですよ。と。

将来の互換性は、当然最優先で解決したい問題ですが、
それを今のコードに複雑性という形で持ち込んで、
初めて使うユーザに「PIGSは遅いね～」と思われたら、将来もへったくれも無い訳ですし。

方向性をしっかり決めておけば、
いま組み込んでも仕方が無い実装については、TPOで対応すればいいんじゃないかと?


ドラえもんのファットバディ(B=129.3cm, W=129.3cm, H=129.3cm)よりも、
ふじこちゃん(B=99.9cm, W=55.5cm, H=88.8cm)のように、絞るトコは絞ったボディがアレゲです。

# 前者を体現したCMSは XOOPS なのかもね

name属性がなくて、POSTされてこなかったっす

先ほどのデバッグの続き。

FirefoxのDOMインスペクタ使って、よーく見比べてみると答えが書いてありました。

＜input id="hoge" type="text" value="hage" /＞ だと POSTで hoge=hage が送られず。

＜input id="hoge" name="hoge" type="text" value="hage" /＞ だと POSTで hoge=hage が送られるようです。

どうにも頭がウニってて、name属性を付け忘れてました。
# XHTML1.1だと、name属性廃止なんだけどもなぁ…


んでもーね。
たしかIE6.0では、 setAttribute('name', *) が仕様のため動きませんとか聞いたことがありますね。そーいえば。
document.createElement('map') とか document.createElement('area') も動きませんし。

ここを参考に、

document.createElement("＜A NAME='AnchorName'＞＜/A＞");

と、ビューティホリィな実装で、なんとかなるらしいんですが、
IEはこんなんばっかりで、さすがにアレです。

IE以外のブラウザは、setAttribute('class', *); でOKなのに、
IEはバグで、setAttribute('className', *); って書かなきゃ動かないとか、
こんなんばっかしです。

createElement()で作成したフォーム部品の値が POSTで送られてこない

久しぶりに書くブログが、PIGS開発日記 のしかも デバッグネタですよ。


よくわからんが、今日は、最後の最後でバグがとれにゃーのですよ。
日本人の9割が爆睡中のAM 4:00にデバッグしてるせいかもしれませんが、
とりあえず今日は、ギヴしようかと思ってコレかいてます。
# 明日のオレがんばれ。

簡単に書くとね、javascript + DOM の話なんだけど、

footprint = document.getElementById(フットプリントID);
eval("footprint.innerHTML = " + '＜select id="hoge"＞' + ";");

って innerHTML を使うと、
POSTしたときに &hoge=値 が飛んでくるんだけど、

var ta1 = document.createElement('textarea');
ta1.setAttribute('id', 'hoge');
ta1.setAttribute('cols', '70');
ta1.setAttribute('rows', '5');
footprint = document.getElementById(フットプリントID);
footprint.appendChild(ta1);

ってやると、 &hoge=文字列 が飛んでこないという現象。

texeareaじゃなくて、＜input type='text'＞ ならいけるんでは… と思い、

var ta1 = document.createElement('input');
ta1.setAttribute('type', 'text');

ってやっても駄目。

DOMで動的に作成したIDを持つ要素が、
POST対象にならないのは変な話なんで、
何らかの見落としがあるんだろうが

innerHTMLがOKで、createElement()がダメってのは、やっぱりおかしい。

# 100% 俺の書いたプログラムがおかしい…

---

せば、最近のPHP-Users で、

「ディレクトリの中身を消すプログラムの書き方を教えてください」
「さくっと再帰処理で書けば?」
「ありがとうございます。いきなり話が変わるのですが、
いろいろと削除を試していて、プログラムが暴走したらしく、予想外のフォルダなどが削除されてしまいました。ゴミ箱には入っていません。何とか修復できないでしょうか。」
「一番簡単なのは あきらめる こと。」
「やけ酒でものめば?」

…

っていう、ほのぼのとした、やり取りがありましたっけなぁ…

その彼は、初めて書いた再帰処理プログラムに、
テスト用のディレクトリ +α をごっそりと削られたんでしょうかね。
大事なディレクトリなんかを。ごっそりと。

んで、手取り足取り丁寧にレクチャーしてくれなかった回答者達を逆恨みして、
腹いせに笑い殺そうとでもしたんでしょうかね?

再帰処理 + ディレクトリ削除処理なんてのは、
素人にはオススメできないロジックNo1.かもしれませんなぁ～。

まぁ、プログラムは書いた通りにしか動かないってことだぁね。