[dss-developer] (Weitere) Add-On Frage

[Lukas Zeller]

Hallo Sergey,

On 30.11.2012, at 10:28, Sergey 'Jin' Bostandzhyan <jin at mediatomb.cc> wrote:

> On Thu, Nov 29, 2012 at 12:38:49AM +0100, Lukas Zeller wrote:
>> Da kämpfe ich mit dem Property-Tree, bzw. mit der Logik der JSON API Methode "query". Gibt's da genauere Doku als die eine Zeile in der JSON API dok? Ist das eine Syntax, die man kennen sollte, oder was dss-Eigenes?
> 
> es ist eine dSS eigene Syntax, detaillierte Doku gibt es nicht, wobei man
> recht schnell dahinter kommt, wenn man ein paar Sachen ausprobiert.

Dachte ich auch, aber ich bin wohl zu blöd ;-) Oder nicht zufrieden, wenn ichs nicht *richtig* verstehe...

> Einige Beispiele finden sich im dSS UI, z.B.:
> /json/property/query?query=/apartment/zones/*(ZoneID,scenes)/groups/*(group,name)/scenes/*(scene,name)

Ja, auf das Beispiel bin ich unterdessen auch gestossen.

> Dies würde heissen: aus allen direkten child Nodes von "zones", gib mir die 
> Werte von den leaf Nodes "ZoneID" und "scenes", falls dieser child Node
> seinerseits einen child Node hat, der "groups" heisst, schau alle child Nodes
> von "groups" an und gebe die leaf Nodes mit den namen "group" und "name" 
> zurück, schau in doer Struktur weiter - gleiches Spiel mit "scenes".

Aha, die geklammerten Namen bezeichnen ausschliesslich leaf nodes?

Ich glaube ich sehe jetzt, was mich vor allem verwirrt hat (und ganz klar sehe ichs immer noch nicht) - die Struktur des Resultats.
Vor allem, dass durch Wildcards im path (ausserhalb der Klammer) auch jeder Leafnode nochmals als Objekt mit einem leeren Array, das so heisst wie der leafnode, erscheint, die eigentlichen Werte der leafnodes dann aber einen Level ausserhalb. 

Ich versuche die Logik zu formulieren, so wie sie sich mir bisher erschliesst: Ist es richtig zu sagen, dass das Resultat pro Ebene ist ein Objekt, das...

...einerseits jeden addressierten leafnode als key:leafValue enthält

...andererseits ein key:childArray enthält, worin
- der key die query auf dieser Ebene des Pfads repräsentiert. Ist die Query im Pfad "*", dann heisst der key so wie das Parent-Element; addressiert die Query einen bestimmten container, dann heisst der key so wie dieser Container. (Diese fallunterscheidung ist mal SEHR verwirrend!)
- der value dieses keys ein array ist, das für ALLE childnodes ein Objekt enthält, mit einem key:array, wo der key so heisst wie der childnode, und der Inhalt des Arrays das resultat der Query auf der nächsten Ebene. Bei Leafnodes ist das ein leerer array.

Ganz hab' ich's noch nicht, denn je nach dem, ob man auf einer Ebene leafNodes abfragt oder nicht, offenbar eine Ebene dazwischengeschoben wird.

> Ich weiss leider nicht wie ich das weniger verwirrend beschreiben kann,
> aber wenn du ein paar Queries im Browser ausprobierst, und daneben den
> Property Tree anschaust, wirst du recht schnell draufkommen wie das System
> funktioniert.

So für die praktische Anwendung, ja. Im Browser probieren was rauskommt, dann dagegen coden. Ich hab unterdessen meine Settings in der UI und kann sie editieren.

Dennoch, ich würde das ja gerne so klar verstehen und formulieren können, dass es auch anderen hilft...

>> Mir scheint, dass der Aufbau des Trees bestimmten Konventionen folgen muss, damit das sinnvoll funktioniert. Ist das so?
> 
> Prinzipiell ja, z.B. wenn du /zones/zone123, /zones/zone456 hast,
> dann sollte als child Node von zone123 noch ein node "name": "zone123" und
> als child Node von zone456 ein Node "name": "zone456" vorhanden sein.

Da bin ich dann gestern spätabends durch Experimente und Vergleich mit Euren add-ons auch draufgekommen, und hab meine Struktur angepasst.

> Ansonsten würdest du bei dem JSON, welches von der Query zurück kommt, nicht
> sehen können zu welchem Node die daten gehören.

Genau das war mein Problem.

> Probiere das Beispiel von weiter oben aus, und lasse das "name" weg, dann wirst
> du sehen was ich meine - die Daten könnte man dann nicht mehr genau einer
> bestimmten Zone zuordnen.

Ja, und so kann man sie natürlich auch nicht in der UI anzeigen :-(

Vielen Dank für die Tips!

Gruss von Lukas