JSON のオブジェクトを ID でリンクする（２）

	describe('sakuraCrowd.linkById', function() {
	it("参照オブジェクトを参照先オブジェクトに変換する", function() {
	var target = [
	{"id":"id1", "value":10},
	{"$ref":"id1"}
	];
	sakuraCrowd.linkById(target);
	expect(target.length).toEqual(2);
	expect(target[0]).toBe(target[1]);
	});

	it("循環参照を検出したら該当する JsonPath を返して警告する", function() {
	var target = [
	{"id":"id1", "value":10, "other":{"$ref":"id2"}},
	{"id":"id2", "other":{"$ref":"id1"}}
	];
	var path = "$[0].other.other";
	expect(sakuraCrowd.linkById.bind(null, target)).toThrow("循環参照です。" + path);
	});
	});

view raw 20140708.spec.js hosted with ❤ by GitHub

gistcf43df70ff1d946640af

JSON のオブジェクトを ID でリンクする - SakuraCrowd’s blog　の関数のテストケースの作成と実装を行いました。

関数の説明は gist のコメントに書きました。

JSONPath でいいんじゃね？->やっぱり ID もいるよね！

リンクを展開していく際に、循環参照を検知したらエラーにして、発生した場所をメッセージで伝える仕様にしました。

その場所の表し方を検討していたところ、 JSONPath という XPath の JSON 版がみつかりました。

「あれ？ ID とか独自仕様作らないで JsonPath でリンクすればいいんじゃね？(｀・ω´・)」と思い始めました。

実際、それですんだら独自仕様なんて面倒なものから解放されるのでよいと思ったのですが、ぐぬぬと思う残念なところがあって、先日の提案どおり ID によるリンクにしました。

残念なところとは、上位へのアクセスを指示する .. が使えないことです。

.. 自体はあるのですが、再帰の指示で使われていて意味が異なりました。

これがないと、同じ階層にある他のオブジェクトを指すために絶対パスが必要になると思います。

ID はプロパティを割り振る手間や重複などのデメリットがありますが、ユーザが簡単にオブジェクトを指すことができます。

もともと、この機能は TMX の中のオブジェクトの設定を簡単にするために作っています。

TMX 自体は XML で表されていて、それを tmx-parser で JavaScript のオブジェクトに変換します。

TMX の編集中に JSONPath を意識するのは難しいので、 ID によるリンクでよいと思いました。

開発環境とかコーディングルールとか

実際のところ、関数の作成よりも開発環境や基本的な書き方の勉強に時間がかかりました。

しかも、まだふわふわしています。

JavaScript のライブラリの書き方（まだふわふわ）

JavaScript によるライブラリの書き方は underscore.js を参考にしました。

無名関数の中で、ライブラリ用のプロパティをグローバル変数に追加します。

同じ名前の変数がすでにある場合は直前まで割り当てられていた値に戻せる関数 noConflict も underscore.js や jQuery を参考にしてやろうと思いましたが、まだ必要性がないと思いやってません。

最低限の機能として、 node.js の場合は exports 変数にライブラリ用の変数を設定するようにしました。

テストフレームワーク Jasmine を使ってみた

Jasmine についてはサンプルを適当にいじっただけです。

Jasmine-standalone はダウンロードして specrunner.html を起動するだけでサンプルが動くし、その中を見れば直感的にカスタマイズできる感じでわかりやすいです。

IDE になじめず軽くへこむ

aptana とか VS express 2013 for web などの IDE も使ってみたのですが、インテリセンスやブレークポイントがうまく使えませんでした。

「俺、向いてないのかな(´・ω・｀)」とまじで落ち込むくらいに、正しい使い方がわかりませんでした。

ブラウザのデバッガがすごい

結局、デバッガは FireFox の F12「要素を調査」を使いました。

chrome の「要素を検証」でもよかったのですが、 cocos2d のサンプルが chrome ではなぜか動かず FireFox では動いたので、 FireFox でやっています。

Jasmine でテストして、失敗したとこだけ、ブレークポイントをはって実行というパターンがわかりやすくてデバッグしやすかったです。

テスト駆動のにわかの感想

テスト駆動だと、修正確認を短いサイクルで行えるので不安要素が少なくなっていじりやすいです。

SakuraCrowd's BlogSpot

このブログを検索