Kombi-Objekte?

IP-Symcon Skripte, PHP, SQL (Fragen)
1

Dies ist primär eine Frage an die Programmierer von IPS:

Gibt es irgendwelche Bedenken, Objekte, die man durch IPS_GetXXX erhält, zu „verketten“, also mit array_merge() in ein „Kombi-Objekt“ zu verwandlen?

Dieser Code würde dazu benutzt:


	$ObjObj = IPS_GetObject( $id );
	switch( $ObjObj['ObjectType'] )
			{
				case 1: $Obj = @IPS_GetInstance( $id ); break;
				case 2: $Obj = @IPS_GetVariable( $id ); break;
				case 3: $Obj = @IPS_GetScript( $id ); break;
				case 4: $Obj = @IPS_GetEvent( $id ); break;
				case 5: $Obj = @IPS_GetMedia( $id ); break;
				case 6: $Obj = @IPS_GetLink( $id ); break;
			};

		$Obj = array_merge( $ObjObj, $Obj );

Die Frage zielt darauf ab, ob die (spezifischen, in IPS_GetObject NICHT enthaltenen) Objekteigenschaften sauber getrennt gehalten werden und ob darauf auch seitens der Programmentwicklung (auch zukünftig) geachtet wird.

Stand heute ist das ja so (swoeit ich nichts übersehen habe), ausser bei der Instanz mit den ChildrenIDs, die aber identisch zu denen des Objekts selbst sind.

Danke.
jwka

2

Naja wenn Du mal in die Doku gesehen hättest, wüsstest Du, dass ChildrenIDs bei IPS_GetInstance die IDs der physikalischen Unterinstanzen enthält. Ich würde die Zusatzdaten in einem untergeordneten Array speichern, wie z.B. $obj[‚AdditionalData‘].

3

Es hat einen einfachen Grund, warum ich das nicht in eine Unterstruktur packen will:

Alle weiteren Code-Bestandteile können dann (ohne Unterstruktur) nämlich unverändert beibehalten werden.

jwka

p.s.: Ja, ich habe die Doku gelesen. Aber der Unterschied erschliesst sich m.E. aus diesen beiden Zeilen der Doku

ChildrenIDs array Untergeordnete InstanzIDs. Siehe: IPS_GetInstanceChildrenIDs

ChildrenIDs array Untergeordnete ObjektIDs. Siehe: IPS_GetChildrenIDs

aber nicht eben sofort, besonders, wenn man „nur“ den Vergleich von zurückgelieferten Keys überprüft - vielleicht sollte man da ein paar Worte zusätzlich spendieren?

Denn diese Zeile

Dieser Befehl ist nur Sinnvoll bei I/O und Splitter Instanzen

steht halt nur bei IPS_GetInstanceChildrenIDs.

4

Hi,
ich habe eben über die Posts und die Doku versucht rauszufinden was Du vorhast (habe es also nicht selbst ausprobiert mit den Code Beispielen) und wie es sich auswirken kann - wenn Du die Felder der Arrays vermischt ist das doch Zufall, ob es klappt bzw. abhängig davon wie die Informationen benannt sind? Oder wie arbeitet das array_merge()?

Ich würde das auch wie Horst beschrieben hat in einem untergeordneten oder anderen Array speichern bzw. mir dann ggf. Hilfsfunktionen dazu bauen. Dann müsste man auch nicht den Code überall anpassen, wenn einzelne Systemfunktionen mal anders reagieren würden - man kann dann einfach den Code der Hilfsfunktion anpassen…

Grüße, Benjamin

5

Also, was ich will ist recht einfach.

Wenn Du auf Objekte zugreifst, musst Du das im Moment oft zweimal tun - einmal mit Get_Object um die (übergeordneten) Objekteigenschaften zu bekommen und dann nochmals mit Get_<objecttype>, um die spezifischen Objekteigenschaften zu bekommen - quasi von einem im Objecttree unsichtbaren Unterobjekt.

So ist’s in IPS gemacht und normalerweise hast Du dann zwei $Objects (was ich eben umständlich finde).

Da ich davon ausgehe, dass die IPS Programmierer nachgedacht haben und Namensüberschneidungen vermeiden (was ich jedenfalls hoffe), ist es ergo kein Problem, die beiden Arrays (immerhin mit den Eigenschaften ein und desselben Objekts!) zu mergen.

Das wird nur dann schief gehen (wie eben bei Instanzen), wenn es überscheidende Key-Namen gibt - wofür ich die Logik nicht so recht erkennen kann und eher von einem Ausrutscher ausgehen würde.

Das angenehme von einem Gesamt-Objekt ist, wie ich schon schrieb, dass mit diesem „Sammelobjekt“ auch jeder Alt-Code und auch von anderen IPS Anwendern unverändert laufen würde (z.B. wenn ich eine Funktionsbibliothek von einem anderen User nutzen würde).

Meine Post zielt also massgeblich darauf ab, zu hinterfragen, ob es denn in Zukunft „zufällige“ Überschneidungen geben wird oder ob es sowas wie eine Eindeutigkeit der Array-Keys je Objekttyp (und Objekt selbst) gibt.

Danke nochmals!
jwka

6

Wenn wir gewollt hätten, dass sich Eigenschaftsnamen nicht überschneiden dürfen, würde ChildrenIDs nicht doppelt vorkommen. Und nein, wir werden das auch nicht ändern und vielleicht, oder vielleicht auch nicht neue doppelte Eigenschaftsnamen einführen.