【KtaiLibrary】バージョンアップ延期と他の不具合報告

icon_ktaiKtai Libraryについて、後ろ向きな情報が連続してしまい申し訳ないです。

まず、前回のKtai Library関連記事で発表したバージョンアップする件なのですが、後述する理由で延期したいと考えています。といっても何ヶ月も後ろというわけではなく、出来れば来週中という短い期間でおさめたいと思います。付近になりましたらまたご連絡いたします。

そして、その理由なのですが…

前回の記事以外にも不具合が報告されてきまして、その対処が結構大がかりなためです。
とりあえず簡単に項目だけ上げておきます。

  • (たぶんAuthの)リダイレクトを経由した場合、SIDが二重につく
  • UTF-8の場合、AUの数値表現(&#xxxx)が文字化けする
  • 同様の理由で、AUの場合、UTF-8にてアクセスキー付きリンクが文字化けする
  • UID入手で、対応していない携帯からのアクセスでNoticeが出る

特に2番目と3番目の問題がかなり深刻で、結果としてファイルサイズがまた大きくなりそうです。簡単に説明すると、AUの数値表現(&#xxxx)用のデータを追加しなければならないためです。

また、新機種携帯の機種情報ですが、そろそろ更新をしなければならないのですが、まだ各キャリア出揃っていないのと、仕様変更をもくろんでいるため、もう少し後になると思います。

ご迷惑をおかけいたします。

でも、最近になってようやくいろんな方に使われ始めて来たようで、こちらとしてもいろいろな情報をいただけて大変に助かっております。
本来なら、BTS等で公開させていただき、すぐに反映できるような体制を整えたいのですが、現時点でものすごく忙しいため、ちょっと見送っています。
できることならcandycaneの事例第一号になりたいなとか思ったり(笑)。
candycaneでコミットできる環境が整ったら、ダメもとで一緒にKtai Libraryを開発していただける方も募集したいなーとか思ったり。
あと、他のフレームワーク用の利用モジュールなどを作っていただける奇特な方も募集したいなーとか思ったり。
ええ、思っているだけです(^^;;;。

【KtaiLibrary】0.1.1で少々深刻な不具合見つかりました

icon_ktai勉強会でご紹介して興味を持たれた方もいらっしゃったかと思いますが(いや、思いたい)、その噂のKtai Libraryに少々深刻な不具合が報告されました。勉強会の報告を書こうと思いましたが、先にこちらの方をお知らせさせていただきます。

▼[cakephp]Ktai-LibraryをComponentで使う時にSessionがスタートしないことがある
http://d.hatena.ne.jp/aroundthedistance/20090520/1242791429

ごめんなさい、完全に私のミスです。
バージョン0.1.1リリース直前に少々修正を施した部分で、しっかりテストせずに出してしまったのが原因です。本当に申し訳ございません。以後このようなことがないようにします。

とりあえず緊急的な対応は上記ブログ記事でOKだと思います(ただし、Session.saveをcakeにしてOKな場合)。
本格的な対応につきましては、月曜日(5/25)のお昼ぐらいまでには最新版(0.1.2)をリリースさせていただく予定でいます。

また、解凍イメージ中に「emoticons」ディレクトリとすべきところを「emoicons」としてしまっているため、これも今回修正します。

皆様にはご迷惑をおかけしたことをお詫びいたします。
そして、不具合をブログにて公開していただいたaroundthedistanceさんには大感謝です。ありがとうございます。

【KtaiLibrary】バージョン0.1.1を公開しました!

icon_ktaiバグフィックス版である「Ktai Libraryバージョン0.1.1」を公開しました。
上記リンク「 Ktai Library for CakePHP1.2 」からダウンロードしてください。

変更箇所は次の通りです。

  • 「session_save」オプションを廃止(Session.saveの値をそのまま引き継ぎます)
  • DoCoMo携帯で、core.php内でConfigure::write(‘Session.save’, ‘php’);以外だった場合にセッションが有効にならない不具合を修正
  • 一部絵文字の不備を修正
  • 「app_controller.php」のファイル名を「app_controller.php.ktai」とし、上書きを防止

絵文字問題を除いて、Session.saveを変更しないのなら特にバージョンアップの必要はありません。まあでも上書きOKですので、バージョンアップは簡単です。最新版に更新していただくことをお薦めいたします。

【KtaiLibrary】勉強会前にバージョン0.1.1が出るかも…

icon_ktaiセッション周りで現在不具合が報告されていて、それを対処するバージョンが勉強会前に出るかもしれません。
先日の「世界一~」の通りに作っていただければたぶん不具合は出ませんが、session.saveを「php」ではなく別のものにするとセッションキーが張り付かないようです。これについては対処をしました。
その他、現象が分からないものがあるため、現在調査しています。その結果次第で、現在不具合が出ているものを全て直したバージョンとして0.1.1を出します。その際に、app_controller.phpを上書きしないように、拡張子を変更する対処を行いますので、新規インストールで若干手間は増えますが安全性は高まると思います。
現在勉強会の準備の方を優先していますので、間に合うかどうかは分かりませんが、出来るだけ間に合わせるように頑張りたいと思います。

また、ちょっとKtaiLibraryからは話がずれるのですが…
これは現時点で本決まりではないので、勉強会でのサプライズには間に合わないのですが(汗)、近日ビッグな報告が出来るかもしれません。今日はそのうち合わせで出かけてきたのですが、なかなか良いお話を貰えたため、モチベーション上がっています。とはいえまだまだ先の話なので、こちらの方は進展ありましたらまたご連絡いたします。

【CakePHP】beforeRedirectに関する挙動について

cake-logo先日、こちら のエントリで話題が出て、チケットも投げてみたのですが、invalidになってしまったのでちょっと記事として書いておきますね。

簡単に書きますと、複数の「beforeRedirectを持ったコンポーネント」をコントローラ内に設置してredirectを呼んだ場合、urlを含む各パラメータが「一番最後に呼ばれたbeforeRedirectの値」になってしまうという問題があります。
つまり、Ktai Libraryを設置し、もしiMODE端末でアクセスされた場合にsidをくっつけるとして、他のbeforeRedirectを含むコンポーネントを設置した場合、場合によってはセッションが切れてしまう問題が発生してしまうのです。

オフィシャルの見解として、1.2ではそのようなパターンは想定外とのことで、1.3に向けての拡張として提案して欲しい、ということでした。まあ、beforeRedirectを必要とするコンポーネントはそうないでしょうから、このような現象は一般的にはそんなに起きないでしょうけど、Ktai Libraryとしては不具合の発生しそうな方法をとることが出来ませんから、今回のapp_controllerで対応したことに関しては結果として良かったと思います。

まあ今回分かったことは、1.2でbeforeRedirectを使う場合は少し注意がいる、ということですね。

【KtaiLibrary】KDDI端末で絵文字「0」が「10」で表示される

icon_ktaiとても恥ずかしいミスが見つかりました。
数字0の絵文字が、KDDI端末で数字10となってしまいます。
0.0.2リリース後に見つけて修正し、0.1.0に盛り込むつもりでいたのですが、いつの間にか先祖返りをしてしまったようです。大変にお恥ずかしい…

修正バージョンの公開は早急に考えますが、とりあえずの対処コードを書いておきます。

【lib3gk.php 1026行】


array(0xf7c9, 0xf0c9),

ohgmaさん、ご指摘いただいてありがとうございました。

【戯れ言】IE8を一言で言えば「腐ってやがる…早すぎたんだ」

nowprintingえ~、いままでかなりIE8を擁護してきたんですが、やっぱり止めることにしました(^^;。

正直言いまして、IE8の最大の難点は「安定していない」ことです。
とにかくハングアップと硬直が多すぎる… 個人的にネットブラウジングしている程度ならまだ良いのですが、仕事では危なくて使えないです。Fiewfoxもたまにありますが、頻度を比べたら桁違いです。
復元機能こそありますが、デバッグ中にこれをやられると非常に困る…
こちらが悪いのかブラウザが悪いのか、検証に時間がかかってしまうので。

そして不具合が発生し、かつハングアップに至らない場合はメモリ内でゾンビ化します。クローズボタンで閉じても、デスクトップ(というかGDIなのかもしれませんが)に居座り続け、画面を埋めます。そして最悪な場合、CPUパワーを食い始め、放置しておくとレスポンスが限りなく遅くなり、最終的にはリセット以外の道が無くなる場合も…

それ以外には特に不満はないです。まあそりゃアドオンが簡単に作れて公開できるのなら言うことはありませんが、まあそれはまだ我慢できる範囲。十分に高速ですし、スタイルシートの崩れについても最小限というのか、だいぶ同じになってきた。Firefoxの不満点であるダウンロードやMIME関連の挙動についてはIEはないため、正直安定しているのならIEを使いたい… と思っていた矢先なので、大変に落胆しているというかまぁ…

というわけで、一言で言えば、あの某ナウシカなあの台詞が思い浮かぶわけです。
ブラウザは安定性命ですよ。特にIEは。

【Ktai】「Ktai Library」バージョンアップ少し延期のお知らせとviewの話

icon_ktai何度もお騒がせしてしまい申し訳ございません。
先ほど「バージョンアップ予定」としましたが、心配していた内容は回避されていたため、少し延期します。

このままでは、やると言ったり止めると言ったり、訳が分からないでしょうから、経緯説明を兼ねて、CakePHPの仕組みについて説明をしようと思います。ちょっとCakePHPの内部の込み入った話をしますので、もしかしたら難しいと感じるかもしれませんが、まあそういうものだと思っていただいてOKです。

発端は、ヘルパーでライブラリ本体である「lib3gk」の初期化をbeforeRender()内で行っているのですが、よくよく考えてみたら、beforeRender()はView::_render()内で「何度も呼ばれてしまうのではないか」という懸念があったからです。というのは、beforeRender()とafterRender()はView::_render()でコールされるのですが、ビューファイルが展開されるたびにView::_render()が呼ばれるからです。ここで言うビューファイルというのは、一般的なビュー以外にもlayoutファイルも含まれ、最低でも2回は毎度呼ばれることになります。つまり、その都度ライブラリがクリアされ、初期化されるようであれば、非常に無駄が発生することになり、バグも生みかねません。

で、結論から言いますと、beforeRenderおよびafterRenderは、ヘルパーが初めて読み込まれた場合、つまり初めてView::_render()が呼ばれた場合だけ行われるため、実害がなかったことが分かりました。なので、現バージョンのままお使いいただいて問題なく、結果バージョンアップは不要だという判断になりました。

そしてその副産物として、今まで不可解だったhelperコールバックのことがやっと少し分かりました。
今回outputがどうしてもうまく受け取れなくて困っていたのですが、この挙動に問題があったようです。

私はCakePHP1.1後期からのCake使いなのですが、RC1が出るまでは、outputはafterRender内でob_get_clean()で受け取るのが一般的な手法で、私もそのように行っていました。ところが、RC1からこの手法が使えなくなり、変わりにView::outputプロパティが受け渡しとして使われるようになりました。そして、この頃からbeforeRender,afterRender以外に「beforeLayout()」「afterLayout()」コールバックが追加されました。

今回KtaiLibraryを実現するにあたり、outputは「afterLayout()」で受け取れば問題なく処理が出来ることが分かりました。方法は

function afterLayout(){
  $view =& ClassRegistry::getObject('view');
  $view->output = mb_convert_encoding($view->output, 'SJIS');
}

という感じです。
ところが、「afterLayoutで受け取れるんだから、初期化はbeforeLayoutだろう」という思惑でいたところ、どうも具合がおかしい。ライブラリのインスタンスが作成されていない状態で、エラーが出てしまいます。初期化はbeforeRenderでやらないとダメなのです。

私は、「beforeLayout()→ (beforeRender()→afterRender()){n} →afterLayout()」の順番で処理が行われると推測していたのですが、初期化はbeforeRenderとなると、「beforeRender()→beforeLayout()→afterLayout()→afterRender()」の順番ではないか? でも実際にはafterRender()では何も入手できない(ob_start()でバッファスタートしているにもかかわらずob_get_clean()では何も入っていない)のです。

想定とは全く違っていました。
「beforeRender()→afterRender()→beforeLayout()→afterLayout()」というのが正しい順番です。

なぜこうなるのか。
それは「View::_render()内で初めてhelperが読み込まれたときだけ」実行されるから、だったのです。
ビューの処理は、まずビューを読み込んでからレイアウト処理を行います。この「まず」の部分でbeforeRenderとafterRenderのコールバックが呼ばれます。次に、レイアウト処理に入って、まずafterLayout。そしてレイアウトファイルをView::_render()を使って読み込むのですが、この中のbeforeRenderとafterRenderは2度目となるので実行されません。そして最後にafterLayoutが呼ばれ、終了…という感じなのです。

なぜこのような仕組みが提供されているのか、その心はさっぱり分かりません。
これでは、afterRenderとbeforeLayoutはほとんど役立たずです。
また、始まりがbeforeRenderで終わりがafterLayoutというのも、なんだかスマートではない…
「beforeLayout()→ (beforeRender()→afterRender()){n} →afterLayout()」という流れが一番自然な気がします。
この流れは改善の余地があるのではないでしょうか?

ちなみに、Ktai Libraryはバージョンアップしたいと言えばしたいです。
うっかりミスをしてしまった箇所がありまして…
なんと、get_version()でとれるバージョン番号が「0.0.2RC4」となってしまっているのです。
バージョン番号を直すのを忘れてしまいました(大汗)。
これだけを直すバージョンアップは、さすがにアレですので(^^;;;

とうわけで、お騒がせしてしまったこと、重ねてお詫び申し上げますm(__)m。

【追記】(2009.11.18)
コールバックの順番ですが、1.2.5(それ以前も?)では修正がされていて、「beforeRender()→beforeLayout()→afterLayout()→afterRender()」の順になっていました。どうやらこの現象はバグだったようです。
icon_ktai何度もお騒がせしてしまい申し訳ございません。
先ほど「バージョンアップ予定」としましたが、心配していた内容は回避されていたため、少し延期します。

このままでは、やると言ったり止めると言ったり、訳が分からないでしょうから、経緯説明を兼ねて、CakePHPの仕組みについて説明をしようと思います。ちょっとCakePHPの内部の込み入った話をしますので、もしかしたら難しいと感じるかもしれませんが、まあそういうものだと思っていただいてOKです。

発端は、ヘルパーでライブラリ本体である「lib3gk」の初期化をbeforeRender()内で行っているのですが、よくよく考えてみたら、beforeRender()はView::_render()内で「何度も呼ばれてしまうのではないか」という懸念があったからです。というのは、beforeRender()とafterRender()はView::_render()でコールされるのですが、ビューファイルが展開されるたびにView::_render()が呼ばれるからです。ここで言うビューファイルというのは、一般的なビュー以外にもlayoutファイルも含まれ、最低でも2回は毎度呼ばれることになります。つまり、その都度ライブラリがクリアされ、初期化されるようであれば、非常に無駄が発生することになり、バグも生みかねません。

で、結論から言いますと、beforeRenderおよびafterRenderは、ヘルパーが初めて読み込まれた場合、つまり初めてView::_render()が呼ばれた場合だけ行われるため、実害がなかったことが分かりました。なので、現バージョンのままお使いいただいて問題なく、結果バージョンアップは不要だという判断になりました。

そしてその副産物として、今まで不可解だったhelperコールバックのことがやっと少し分かりました。
今回outputがどうしてもうまく受け取れなくて困っていたのですが、この挙動に問題があったようです。

私はCakePHP1.1後期からのCake使いなのですが、RC1が出るまでは、outputはafterRender内でob_get_clean()で受け取るのが一般的な手法で、私もそのように行っていました。ところが、RC1からこの手法が使えなくなり、変わりにView::outputプロパティが受け渡しとして使われるようになりました。そして、この頃からbeforeRender,afterRender以外に「beforeLayout()」「afterLayout()」コールバックが追加されました。

今回KtaiLibraryを実現するにあたり、outputは「afterLayout()」で受け取れば問題なく処理が出来ることが分かりました。方法は

function afterLayout(){
  $view =& ClassRegistry::getObject('view');
  $view->output = mb_convert_encoding($view->output, 'SJIS');
}

という感じです。
ところが、「afterLayoutで受け取れるんだから、初期化はbeforeLayoutだろう」という思惑でいたところ、どうも具合がおかしい。ライブラリのインスタンスが作成されていない状態で、エラーが出てしまいます。初期化はbeforeRenderでやらないとダメなのです。

私は、「beforeLayout()→ (beforeRender()→afterRender()){n} →afterLayout()」の順番で処理が行われると推測していたのですが、初期化はbeforeRenderとなると、「beforeRender()→beforeLayout()→afterLayout()→afterRender()」の順番ではないか? でも実際にはafterRender()では何も入手できない(ob_start()でバッファスタートしているにもかかわらずob_get_clean()では何も入っていない)のです。

想定とは全く違っていました。
「beforeRender()→afterRender()→beforeLayout()→afterLayout()」というのが正しい順番です。

なぜこうなるのか。
それは「View::_render()内で初めてhelperが読み込まれたときだけ」実行されるから、だったのです。
ビューの処理は、まずビューを読み込んでからレイアウト処理を行います。この「まず」の部分でbeforeRenderとafterRenderのコールバックが呼ばれます。次に、レイアウト処理に入って、まずafterLayout。そしてレイアウトファイルをView::_render()を使って読み込むのですが、この中のbeforeRenderとafterRenderは2度目となるので実行されません。そして最後にafterLayoutが呼ばれ、終了…という感じなのです。

なぜこのような仕組みが提供されているのか、その心はさっぱり分かりません。
これでは、afterRenderとbeforeLayoutはほとんど役立たずです。
また、始まりがbeforeRenderで終わりがafterLayoutというのも、なんだかスマートではない…
「beforeLayout()→ (beforeRender()→afterRender()){n} →afterLayout()」という流れが一番自然な気がします。
この流れは改善の余地があるのではないでしょうか?

ちなみに、Ktai Libraryはバージョンアップしたいと言えばしたいです。
うっかりミスをしてしまった箇所がありまして…
なんと、get_version()でとれるバージョン番号が「0.0.2RC4」となってしまっているのです。
バージョン番号を直すのを忘れてしまいました(大汗)。
これだけを直すバージョンアップは、さすがにアレですので(^^;;;

とうわけで、お騒がせしてしまったこと、重ねてお詫び申し上げますm(__)m。

【追記】(2009.11.18)
コールバックの順番ですが、1.2.5(それ以前も?)では修正がされていて、「beforeRender()→beforeLayout()→afterLayout()→afterRender()」の順になっていました。どうやらこの現象はバグだったようです。