まだまだ続くよ第4章 part4

ソート可能な子ノードについてとNamespaceのさわりについてのお話。

4.4 Orderable Child Nodes（つづき）
子ノードがソート可能の場合で、Node.orderBefore()とかを使う。

4.4.1 Orderable Same Name Siblings
同名のノードが存在した場合でも問題なく指定は可能。

[A, B, C, A, D]っていう子ノードが存在していて、親ノードの設定でソート可能の設定がされている場合にNode#orderBefore("A[2]","A[1]")を呼ぶと[A, A, B, C, D]って取得できる。API的には、orderBefore(String 移動元ノード,String 移動先)となって、要は最初の配列でいうところの4番目のAノードを1番目のAの前に移動しろという命令。しかも、すごいのはこの命令後は実際にsave時に順序が入れ替わって保存される。なのでこの後でA[1]に相当するのは命令前のA[2]になるということ

4.4.2 Non-orderable Child Nodes
Node.getNodes()で取得される順番は保証されないので(実装によって異なってくる）、順番に依存したアプリケーションにするなって。

4.4.3 Orderable Child Node Support is Optional
そのまま。

4.4.4 Properties are Never Orderable
これもそのまま。

ってのが仕様で定義されている。思っていた”Orderable”とだいぶ違った。。。orz
4.4.1って仕様で定義すべきことなんだろうか。。。

4.5 Namespaces
ノードやプロパティにはプレフィックスをコロンで区切って表現する、これがNameSpace。名前衝突の解決を図るのが目的。JCR準拠のリポジトリは以下の組み込みnamespaceが必要。

jcr 組み込みノードタイプ用
nt 組み込み主ノードタイプ名用
mix 組み込みmixinノードタイプ名用
xml XMl互換用
”” デフォルトnamespace.

level1ではnamespaceは特定のsessionから一時的にオーバーライドできる。
level2ではnamespaceの追加、削除ができる。

level1の場合のいってることはよくわからんが6.3章で詳細はわかるらしい。。。
ここでは上記レベルの認識だけでよさそうだ。

4.6 Path Syntax
パスの記述のシンタックスが表記されている。必要時確認すればよくてここでは書かない。

4.6.1 Names vs. Paths
specの表現としてmyapp:paragraphはnameと表現しmyapp:paragraph[3]とブランケッツがつくとパスと表現しているようだ。