Unofficial Planet WordPress Japan

今回は、技術的なネタを書いてみようと思います。二回に分けて書こうと思います。今日はですます調な気分です。

ネタは、3ヶ月程前にはまった内容にしてみようと思います。前々から忘れてしまう前にポストしないとなぁと思いながら、先延ばしにしていました。問題としては、以下のように当時は書いておりますね。

draggableな要素がoverflowのhidden, scroll, auto(たぶん)のときには、そのoverflowを指定してある要素の外では見えなくなっちゃう。

また、この問題はscript.aculo.usの開発者も知っているのだけど、なかなか対応が面倒なもののようです。こんな感じに言っていますから。

I discussed this with Thomas some time ago, and the problem is that the element we move (be it in ghosting mode or not) usually must remain at the same DOM level because otherwise, styles might get lost. I'm working on a solution right now, too, it will involve a new option you can use to assign a class name to the element while it's being dragged. If this class name is supplied, the element will be attached to the body. Let's see if this works, I'll provide the patch as soon as it is ready

一応、closedとなっており、 Effects Treasure Chestにその解決方法が上がっているのですが、以下の質問があるように、私もこのソースでは、実際に動いているところを見たことがありません。動作は見ていないのですが、ソースを軽くみたら、がんばったら動きそうな感じがしますけどね。そして、この方法は、実際のライブラリには組み込まれていません。

Could you show an example of how to use this effect?

Edit 01/08/2007 by Greg Hinch – added a line to turn this.dragging on and off when calling initDrag() and finishDrag(). This was to fix an issue where if a draggable was clicked but not dragged the duplicate element would not be removed from the page.

さて、この問題は、scrollなdivの要素の下にDragオブジェクトがあったら、そのdivを乗り越えることができないというものです。これはライブラリの問題ではなく、ブラウザの実装の話です。そういう仕様なのですね。まぁ、IE6では大丈夫だけど、IE7、Mozillaではダメというのがなんともやるせないですが。

実際どういう状態になるか、簡単にスクリプトを書いてみました。
下のページを見てください。

Drag object over scroll div(Not Working!)

右ペインにあるtakoとかikaといったdiv要素はドラッグが可能です。しかし、右ペインから左ペインにドラッグしようとすると見えなくなってしまいます。この状態をなんとかしたいのです。さらに不思議なことに、見えなくなっても、実はドロップすることはできます。再び書きますが、おそらくIE6ではちゃんと左ペインにDragオブジェクト持っていってもちゃんと見えると思います。確認はしていませんが、3ヶ月前に調査したときは、IE6では想定した動作をしていました。

JavaScriptの方では、動かないバージョンでは以下のようになっています。

大したことはしていません。class属性の値にdrag-objを持つ要素をドラッグ可能にしています。また、id属性の値にdrop-containerを持つ要素をドロップ可能にしており、ドロップした際に、その要素のinnerHTMLにドラッグ要素のテキストを書き足します。

そして、CSSの方で重要な場所が以下のようになっています。

別にscroll-aはoverflowがscrollでなくてもいいのですが。。。あと、overflow-yって、IEだけだと思っていましたが、手元のfirefoxでは動いたので、とりあえずこれでいきます。

今回はここまでです。動く方のソースは実はまだ頭の中で、ソースには書き出してはいません。どうやるか、ということですが、Dragオブジェクトをscroll-bの下ではなく、body直下に置く、もしくは、scroll指定していない場所に置くという方法を採用する予定です。

来週中に書くことを目指します。

そういえば、2ヶ月振りにscript.aculo.usを使いました。いつの間にか1.8.0が出ていましたね。prototype.jsのバージョン1.6ともcompatibleでうれしい限りです。

タイトルにYUIとか書くと全く関係ないところが、キーワードを拾って、リンクを張ってきやがる。日本人にとって、YUIという言葉は、普通Yahoo! User Interfaceなんかではなく、人の名前になる。しかも、女性の可能性が高いので、リファラーがYUIだらけに。

というわけで、YUIを最近使っているわけだが、イテレートするのにfor文を書くのが嫌なので、eachとmapだけでも、prototype.jsから移植してみた。勝手に、YAHOO.util.Collectionと名前を付けてみたりw。改め、YAHOO.utilx.Collectionにした。また、使いそうなコレクションがあったら追加してみる予定。別に、anyやらallやら全部prototype.jsから持ってきてもいいのだけど、面倒なので必要があれば実装するし、使わなければ実装しない。
というわけで、以下がソース

次のように使う。配列のとき

オブジェクトのとき

とりあえず、for文を書きたくないので、これで少しすっきりした。

(more...)

Module Pattern祭があったのは、今年の6月だったみたいですね。まだ時代の流れに遅れていますが、少しずつ追いかけていこうと思います。

現在は、jQueryでもprototype.jsでもなく、YUIを調査しています。まだまだ頭がprototype.js脳なので、多少苦しんでいますが、だいぶ掴めてきました。そして、YUIでも直接呼び出せばいいような小さなプログラムは書けるようになってきました。

ところで、prototype.jsでは、Class.createされるとinitializeが呼ばれ、ほげほげするように書きますよね。

とか。そして、それなりに大きいプログラムでもクラスごと（こんなことを言ったら怒られる？）に分けて、整理して構成することができますね。

どうやったら上のように、そしてYUIっぽく書けるかな、と昨日の晩から調査をしていました。そして、ようやくその手がかりとなるポストを見つけることができました。（別にYUI以外でもこの書き方していいけど。。。）
A JavaScript Module Patternです。名前はこのポストの著者のEricさんが勝手に付けたっぽいのですが、いいです。これ。日本でも半年前に話題になっていたみたいですね。時代遅れですいません。

クロージャを使うことによって、privateメンバっぽく書けるのもうれしいですね。上の例では、結局varAとvarBはpublicメンバとして評価されてしまうので、適当なコーディング規約がないとグループで開発したときに呼び出してしまいそうです。

そして、そのポストで紹介されていたような書き方は以下の通り。

これだとvarAとvarBがHogeの中からしか参照できません。そして、returnでalertAという関数オブジェクト（メソッドのように使う）を持ったオブジェクトを返してくれます。

これからはこれで行こうと思います。

また、JavaScriptでは、無駄にnewをしない方がいいようです。YUIの調査をしていたら私のヒーローのDouglasさんがそうおっしゃっています。
JavaScript, We Hardly new Ya
なんでもprototypeオブジェクトを無駄に持ってしまうことが問題であるとおっしゃっているのです。つまり、メモリの無駄遣いは止めましょうとのことです。そのため、newしない方がいいそうです。というか、newすると時代遅れだそうです。

てっきり、prototypeオブジェクトにいろいろ書いておくと、newされたオブジェクトが使いまわしてくれるので、積極的にprototypeオブジェクトを使用して、newでオブジェクト生成し、それを使っていくのが通だと思っていたのですが、そうでもないのですね。

ただDouglasさんは、newを使用するときもなくはない、と言っています。私のpoorな頭ではどんなときにnewを使用した方がよいのか、ということがわかりませんでした。何度もそのオブジェクトを作成する場合と理解したらいいのでしょうか？

どちらにせよ、Douglasさんを信じて、あまりnewをしないように、prototypeオブジェクトは使用しないように今回は作っていこうと思います。

しかし、まだまだprototype.js脳から離れられていないので、Array.eachやらArray.mapやらのイテレーション系の関数がないのは苦しいです。自作しようかしらん。

次は、CustomEventが使えるようになりたいです。この辺がまだ理解できていませんので、読んでいきます。きっとここら辺が理解できたら、YUIでそれなりのプログラムが書けそうです。
Event-Driven Web Application Design
The Bubbling Technique & Custom Event, YUI’s Secret Weapon by Caridy Patiño Mayea

removeChildのみならずreplaceChildのときも必要！さらに、innerHTMLで内でEventを指定していた要素にも必要！

前からIE6にはメモリリークがあるってことは知っていた。そして、要素同士が双方にポインタを持つこと？で、そのメモリリークが起こると知ってはいた。そして、それを避けるべきだということも言葉では理解していた。でも、実際にどうすればいいの？ってことがわからなかったのだ！そして、つい先ほど、その問題解決がわかった！！！超感動！

確かに最近開発したWebアプリでは、再読み込みをする度に重くなっていき、絶対メモリリークしているなってことに気づいていた。でも、だからってどうしたらいいかはわからなかった。って、それはそれで問題なのだけど、こうやってわかった以上は早速月曜日に修正するぜ！

で、どうやって気づいたかというと、YUI TheaterのDouglas Crockford氏のThe Theory of the DOMからだった。いいよ！いいよ！Qualityも良かったけど、本当に勉強になるっす。一応3つも映像があって、全部で一時間半弱なんだけど、見てよかった！ここには、そのメモリリークについて話があったPart3を貼り付けておく。メモリリークの話だけなら、Part3の最初の6分くらいなので、それだけチェックしてもいいかも。

で、講義の中で上げられていた削除する前にイベントを削除する方法としては、上の映像では次の関数を使用していた。実際に動かしていないから間違っているかもしれんけど、だいたいこんな感じ。

もしくはYUIのpurgeElementで指定した要素以下の要素のイベントを一掃してくれるとのことだ。
まぁ、方法がわかれば簡単に作れるさ。prototype.jsなどでElement.remove()とかしているところもremoveする前にイベントを一掃しないとメモリリークしてしまうので、気をつけないといけない。私の問題はまさにこれだったと思う。というわけで、Douglasさんのファンになりましたので、当分YUIを調べることになりそうす。
うーむ。やってみたけど、メモリが開放されない。。。なんでだろ。dragdrop.jsのdraggableをたくさん作って、その上のDIVコンテナのinnerHTMLを書き換えているので、おそらくdraggableな要素が無くなってもメモリは持っているかのようだ。。。ちょっと調査せなかんな。

つーか、Wordpressのバージョンを上げたらwysiwygエディタを消すオプションが無くなってた。。。orz
ソースコードのスペースを勝手に削りやがって！！！！空行も削りやがる。許せん！くそー。腹が立ってきた。
って、少し調べたら私の他にも腹が立っている人はいるみたい。
Idea: Option to turn off WYSIWYG editor, sitewide!
解決方法がtinymceのディレクトリを削除しろだって？やってらんねー。
(more...)

昨日からはてブで賑わっている「一行でIEのJavaScriptを高速化する方法」を試したのだけど、私の環境では全く速くならんかった。記事を読んだときは、私も「これはすごい」と思って、今朝早速、最近ずっと開発していた場所に組み込んでベンチを取ってみたのだけど、全く変わらないという結果が出た。 まず、 IE では document にそのままアクセスすると window オブジェクトの内部メソッドが実行されてしまいます。これが非常に重いのです。 まぁ、確かに理解はできるし、軽くなりそうな気がするけども、実際はdocumentを呼ぶ機会は少ない（DOMで検索した要素もキャッシュ化している）ので、高速化されなかったってことかな。きっと、 この方法は document と書かれた部分を 5 倍以上（ループのコストを引くとたぶん 10 倍以上？）速くすることができるのですが、その数倍というのは「プロパティアクセス」と「関数呼び出し」の差です（関数呼び出しを減らしていると考えてください）。 ですので、ほとんどのウェブサイトでは効果はあまり感じられないかもしれません。 とのことなので、私のスクリプトが重いのはDOM検索なので、変わらなかったんだろうな。 つーか、変数の初期化に関しては、勉強になったよ。特にJavaScript高速化 - まさにっき（使えないプログラマーの記録）の「とおりすがり」氏、説明わかりやすい！というわけで、私もメモとして書かしてもらおうっと。 とおりすがり 『> これもまた、 JavaScript では変数はスコープの先頭で生成されるため、 document は空の変数となり undefined になってしまいます。 例えば var foo = 1, bar = 2; var foobar = foo + bar; なんていう宣言があった場合、 var foo = bar = foobar = undefined; //宣言された変数はスコープの最初に全部まとめて生成される。 foo = 1; bar = 2; foobar = foo + bar; みたいに解釈されます。なので var [...]

昨日からはてブで賑わっている「一行でIEのJavaScriptを高速化する方法」を試したのだけど、私の環境では全く速くならんかった。記事を読んだときは、私も「これはすごい」と思って、今朝早速、最近ずっと開発していた場所に組み込んでベンチを取ってみたのだけど、全く変わらないという結果が出た。

まず、 IE では document にそのままアクセスすると window オブジェクトの内部メソッドが実行されてしまいます。これが非常に重いのです。

まぁ、確かに理解はできるし、軽くなりそうな気がするけども、実際はdocumentを呼ぶ機会は少ない（DOMで検索した要素もキャッシュ化している）ので、高速化されなかったってことかな。きっと、

この方法は document と書かれた部分を 5 倍以上（ループのコストを引くとたぶん 10 倍以上？）速くすることができるのですが、その数倍というのは「プロパティアクセス」と「関数呼び出し」の差です（関数呼び出しを減らしていると考えてください）。

ですので、ほとんどのウェブサイトでは効果はあまり感じられないかもしれません。

とのことなので、私のスクリプトが重いのはDOM検索なので、変わらなかったんだろうな。

つーか、変数の初期化に関しては、勉強になったよ。特にJavaScript高速化 - まさにっき（使えないプログラマーの記録）の「とおりすがり」氏、説明わかりやすい！というわけで、私もメモとして書かしてもらおうっと。

とおりすがり 『> これもまた、 JavaScript では変数はスコープの先頭で生成されるため、 document は空の変数となり undefined になってしまいます。

例えば var foo = 1, bar = 2; var foobar = foo + bar; なんていう宣言があった場合、
var foo = bar = foobar = undefined; //宣言された変数はスコープの最初に全部まとめて生成される。
foo = 1; bar = 2; foobar = foo + bar;
みたいに解釈されます。なので
var doc = document; var document = doc; は
var doc = document = undefined; doc = document; document = doc;
になって undefined になるんですよ。

> 2行目の時点での doc が undefined になっているのか？
var document; がある時点で、そのスコープに入った瞬間に document が undefined になるわけです。
と、全然関係ない通りすがりでした。』 (2007/10/11 08:05)

あと、amachangさんの言っているevalのタイミングについても勉強になった。

eval で var 宣言することでスコープ途中から変数を生成することができるのです。

しかし、

といった、いかにも黒魔術的な書き方はハックって感じがするね。

当分の間JavaScriptオンリーです。今日はですます調です。 Ajaxのローディングとかでクルクル回るアニメーションGIFてありますよね？あのローディングのアニメーションGIFをJavaScriptで重い処理をするときに使おうと思っていてその画像を探していました。そして、先日調べていたら、こんなサイトを発見しました。激しくいいですね。 Ajaxload - Ajax loading gif generator 実は、結構有名なサイトなんですね。知らなかったです。でも、先日知って、早速作ってみました。 そして、早速使おうと思ったのですが、重い処理をしている間にアニメーションGIFを表示させていてもアニメーションがされないのです。。。つまり、アニメーションではない状態のGIF画像が表示されるだけなのです。その原因はJavaScriptが処理されている間だからです。また、重いJavaScriptが処理中の際にはその間はブラウザが固まります。 その解決方法を探していたのですが、その際にようやく私もsetTimeoutの使いかたがわかりました。そして、ページ描画のタイミングを制御できるようになりました。そうです。ポイントはsetTimeoutです。重い処理を一つの関数に入れちゃダメなんですね。つまり、これはダメなのです。 JAVASCRIPT: Event.observe(window, 'load', function() {         var loadingImage = Builder.node('img', {src: 'loading.gif'});         var sync = $('sync');         var async = $('async');         var loading = $('loading');         var working = $('working');         var loop = $('loop');       [...]

当分の間JavaScriptオンリーです。今日はですます調です。

Ajaxのローディングとかでクルクル回るアニメーションGIFてありますよね？あのローディングのアニメーションGIFをJavaScriptで重い処理をするときに使おうと思っていてその画像を探していました。そして、先日調べていたら、こんなサイトを発見しました。激しくいいですね。
Ajaxload - Ajax loading gif generator
実は、結構有名なサイトなんですね。知らなかったです。でも、先日知って、早速作ってみました。

そして、早速使おうと思ったのですが、重い処理をしている間にアニメーションGIFを表示させていてもアニメーションがされないのです。。。つまり、アニメーションではない状態のGIF画像が表示されるだけなのです。その原因はJavaScriptが処理されている間だからです。また、重いJavaScriptが処理中の際にはその間はブラウザが固まります。

その解決方法を探していたのですが、その際にようやく私もsetTimeoutの使いかたがわかりました。そして、ページ描画のタイミングを制御できるようになりました。そうです。ポイントはsetTimeoutです。重い処理を一つの関数に入れちゃダメなんですね。つまり、これはダメなのです。

あ。ちなみにprototype.jsとscript.aculo.usがあることを前提に書いているので、その辺は適当にほげほげしてください。まぁ、ここではsetTimeoutを使用して、その中で重い処理を実行していますね。処理を始める前にアニメーション画像を出して、処理が終わる際にローディングの画像を消す処理をしています。そして、while文の中を勝手に重い処理としてここでは使用しています。しかし、このwhile文が流れている間、いや正確にはcallback関数が実行されている間はアニメーションGIFが止まります。

そこで、アニメーションGIFを止めないような方法を考えました。その根本にある考えは。。。重い処理は一つの関数に入れないということです。つまり、一つ関数の中にループで重い処理を実行させるのではなく、再帰を使用して何個も関数を呼び出す必要があります。もちろんそれが再帰処理ができないような重い処理であればこの方法は無理ですが、往々にして重い処理というのはDOMを使ってイテレーションを使用するところになる可能性が高いと思いますので、それを再帰処理に置き換えましょう。そして、修正したコードは以下の通りです。

これで、重いループををしていても、だいたいの場合はアニメーションGIFが止まらずに済みます。「だいたいの場合」と書いたのは理由があります。実は、私の実環境では、もっと重い処理をしなければいけない用件がありましたので、修正版でもアニメーションGIFが動きませんでした。正確にはfirefoxでは大丈夫でした（たぶんそれほど重くなかったのが原因かもしれません。）が、IE6ではアニメーションGIFが止まりました。原因は、再帰の中で呼び出しているsetTimeoutのmillisecondの値でした。私はどうせ次の処理を実行してもらうのだから0でいいのではないか、と考えていたのですが、0だとすぐ関数をエンキューするのはいいのですが、現在走っている処理が終わると、すぐキューにたまった関数をデキューして実行するので、JavaScriptの処理が常に動いていることになったようです。あくまで想像ですが。なので、ここにラグを与える必要があったのです。そこで、setTimeoutに渡すmillisecondの値を適当な数値に変更すると、カクカクするけど、アニメーションGIFが動いてくれました。
動くサンプルは以下に置いておきます。ちなみにこのサンプルはカクカクしません。
Animation GIF and JavaScript setTimeout

404 Blog Not Found:javascript - ページはいつ再描画されるかが激しく参考になりました。

先日、jQuery開発者向けメモを見て、一通り試してみましたがなかなか直感的に書けそうなライブラリなので今後使用することを検討してみます。今、開発の勢いが一番あるライブラリなので追いかけたりするのが楽しそうですね。prototype.jsとscript.aculo.usは、なかなか新たなリリースが無く、ちょっとさみしいですが、これはこれでライブラリとして成熟段階に入ったといことでアリなのでしょうね。

さて、本日はTOEICを受けてきました。過去に２回ほど受けたのですが、相変わらず時間が足らなかったです。問題が中途半端に全問解けそうなので、ついついちゃんと読んでやってしまうのが原因です。そのため最後に15問ほど残ってしまいます。スピード勝負はつらいですね。でもまぁ、おそらくそれなりのスコアは出たでしょう。試験地の愛知大学が思ったよりもとてもキレイでした。

先日激しくヘコむことがありましたが、ようやくすっきりしました。今日から強く生きていこうと思います。

というわけで、もういっちょ。考えていたDOM検索効率を考えたメソッド群を作ってみた。 ええと、prototype.jsのElementオブジェクトにaddMethodsしていることからもわかるようにprototype.js必須っす。ええと、私の使っているprototype.jsは、1.5.1ね。script.aculo.us（v1.7.1_beta3）と一緒に使っているので。 JAVASCRIPT: document.getElementsByClassNameAndTagName = function(className, parentElement, tagName) {   if (Prototype.BrowserFeatures.XPath) {      return $(parentElement).getElementsByClassName(className);   } else {     var children = $(parentElement).getElementsByTagName(tagName || '*');     var elements = [], child;     for (var i = 0, length = children.length; i <length; i++) {       child = children[i];       if (Element.hasClassName(child, className))         elements.push(Element.extend(child));   [...]

やったよ。やった。ようやくキーボードが届いたよ。ここ3ヶ月、私のキーボードはC-xと]}のキーが壊れていたのだけど、ようやく快適に打てるようになったよ。私の状態を見兼ねて買ってくれた学生時代の恩師の稲葉先生どうもありがとうございます。つーか、そのくらい自分で買えばいいのだけど、なんか買う気がなかなか起こらなくて、ダラダラしてました。。。 で、さっそく簡単なプログラムを書きはじめている。えと、実はまだDOM検索周りを調べているのだけど、一つ疑問があがってきた。それは以下の通り。 childNodesでの検索とfirstChildとnextSiblingの検索について。つまり、どちらでも子ノードを取得することができるのだけど、実際どっちを使ったらいいの？ ググってみるとパフォーマンスを見ている人がいたのだが、childNodesよりも、fistChildを取ってnextSiblingで検索する方が速いということらしい。特に、IE6が良くないとのこと。ブラウザの実装によるのね。。。 new Blah().list(); node.childNodes[] performance うーむ。てっきりnextSiblingって、いかにもリンクリストな感じでその要素の数を線形探索しないといけないから、O(log(n))で、childNodesでindex指定で取得したら、O(1)で速いんだろうなぁ、なんて思っていたのだけど、どうやらそうでないみたい。。。と鵜呑みにするのもどうか、と思うのだが、まぁ、いいや。 ええと、何でこんなことを調べているかと言うと、私はchildNodesからelementNodeだけの配列を取得するようなメソッドが欲しかったので、作ろうと思っていたのだ。そして、その際に、firstChildからnextSiblingでグルングルン回すか、childNodes分こっちもグルングルン回するかどっちにしようかな、と思っていたのだ。そこで自分でベンチマークを取ってみたよ。まぁ、結局、全てを線形探索するのだから、どっちでもいいような気がするけども。。。で、ベンチマークツールはamachang氏のbenchmark.jsを使用した。 ソースはこんな感じ。ここにサンプルも置いておくよ。childNodes && firstChild + nextSibling Benchmark HTML: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html lang="ja">   <head>     <meta http-equiv="Content-Type" content="text/html; charset=utf-8">     </meta><meta http-equiv="Content-Style-Type" content="text/css">     </meta><meta http-equiv="Content-Script-Type" content="text/javascript">     <script language="JavaScript" type="text/javascript" src="js/prototype.js"></script>     <script language="JavaScript" type="text/javascript" src="js/scriptaculous.js"></script>     <script language="JavaScript" type="text/javascript" src="benchmark.js"></script>     <script language="JavaScript" type="text/javascript">       Element.addMethods({         [...]

というわけで、もういっちょ。考えていたDOM検索効率を考えたメソッド群を作ってみた。

ええと、prototype.jsのElementオブジェクトにaddMethodsしていることからもわかるようにprototype.js必須っす。ええと、私の使っているprototype.jsは、1.5.1ね。script.aculo.us（v1.7.1_beta3）と一緒に使っているので。

nextElement, previousElementはそのまんま。textNodeはすっ飛ばして、elementNodeだけを見ている。firstChildElementとlastChildElementはfirstElementとlastElementって命名しようかと思ったけど、childだということを意識したかったのでちょいと冗長だけど、これで堪忍してや。で、意味もそのまんま。textNodeをすっ飛ばして最初や最後のelementNodeを返す。

childElementsは、前回のポストの結果を考慮してfirstChildとnextSiblingを採用。elementNodeの配列を返す。childElementは、index指定でelementNodeを返す。本当は、こんな感じでchildElementsメソッドの返す配列のindexを返す方がすっきりしていていいんだけどなぁ。

しかし、それだとnextSiblingを全て見てまわってしまうので、遅くなりそうなので、不採用。

cleanWhitespaceRecursiveはついでの産物。今回作成したものとは関係がないのだけども、一応。HTMLコーダにじかにHTMLを書かれるとwhitespaceが入ってしまい、困るので再帰的に消してみることにした。JavaScriptで再帰をするときってやっぱり、ローカル変数に関数をぶちこんで、それを何度も呼び出す方がいいのかな、と思ったので、自分自身を何度も呼び出すような方は不採用。
自分自身を呼び出すのは、こんな感じか。

どっちがいいんだろうなぁ。。。

で、本当は、オプションで、$指定で返すか、そのままのelementを返すかを指定できるようにするかで迷ったのだけど、prototype.jsと一緒に使うことを前提としているので、$で返すようにした。これもパフォーマンスに関係してくるんだけど、まぁ、その辺は考慮中。

つーか、また後で追記したり、ソース修正するかもしれん。名前はなんでもよかったのだけど、domx.jsとしよう。

ソースはここ。

domx.js
ライセンスは適当っす。自己責任で使ってちょ。

で、上のソースを動かす形にしたデモもここに置いておく。domx demo

うーん。そろそろjQuery使ってみようかなぁ。。。onReadyとか便利そうだし。。。インデントがタブなのが非常に嫌なので、敬遠しているのだけど。。。

全然関係ないが、ここ二日ほど愛知県図書館で開発をしている。なかなか良いね。ホットスポットもあるみたいだけど、契約をしていないのでインターネットにつなげない。でも、そのおかげで効率がいいよん。インターネットがあるとダラダラしちゃって、ダミだ。

やったよ。やった。ようやくキーボードが届いたよ。ここ3ヶ月、私のキーボードはC-xと]}のキーが壊れていたのだけど、ようやく快適に打てるようになったよ。私の状態を見兼ねて買ってくれた学生時代の恩師の稲葉先生どうもありがとうございます。つーか、そのくらい自分で買えばいいのだけど、なんか買う気がなかなか起こらなくて、ダラダラしてました。。。

で、さっそく簡単なプログラムを書きはじめている。えと、実はまだDOM検索周りを調べているのだけど、一つ疑問があがってきた。それは以下の通り。

ググってみるとパフォーマンスを見ている人がいたのだが、childNodesよりも、fistChildを取ってnextSiblingで検索する方が速いということらしい。特に、IE6が良くないとのこと。ブラウザの実装によるのね。。。
new Blah().list(); node.childNodes[] performance
うーむ。てっきりnextSiblingって、いかにもリンクリストな感じでその要素の数を線形探索しないといけないから、O(log(n))で、childNodesでindex指定で取得したら、O(1)で速いんだろうなぁ、なんて思っていたのだけど、どうやらそうでないみたい。。。と鵜呑みにするのもどうか、と思うのだが、まぁ、いいや。

ええと、何でこんなことを調べているかと言うと、私はchildNodesからelementNodeだけの配列を取得するようなメソッドが欲しかったので、作ろうと思っていたのだ。そして、その際に、firstChildからnextSiblingでグルングルン回すか、childNodes分こっちもグルングルン回するかどっちにしようかな、と思っていたのだ。そこで自分でベンチマークを取ってみたよ。まぁ、結局、全てを線形探索するのだから、どっちでもいいような気がするけども。。。で、ベンチマークツールはamachang氏のbenchmark.jsを使用した。

ソースはこんな感じ。ここにサンプルも置いておくよ。childNodes && firstChild + nextSibling Benchmark