Update auf 2.10 Skriptprobleme

Archiv Allgemeine Diskussion (2.x/3.x)
1

Hallo zusammen,

habe heute nun auch meine Subscription verlängern können und natürlich nach einem Backup direkt das Update auf 2.10 durchgeführt.

Direkt nach dem Start wurde ich natürlich von Fehlermeldungen in den Skripten erschlagen. Genau die beiden Funktionen die sich geändert haben, hatte ich natürlich auch in Verwendung :wink:

Habe mal grob die „alten“ und „neuen“ Varianten gegenübergestellt und kann noch nicht ganz nachvollziehen, warum Funktionen komplett wegfallen bzw. in ihrer Funktionalität komplett geändert werden…

Bsp: IPS_GetStatusVariables


//alte Variante
foreach (IPS_GetStatusVariables($InstanzID) as $StatusVar)
{
  ...
}					

//Neue Variante
foreach(IPS_GetStatusVariableIdents($InstanzID) as $StatusVarString)
{
  $StatusVar = IPS_GetStatusVariable($InstanzID, $StatusVarString);
  ...
}

Bsp: Erstellen eines Event per Skript, welches als Skript sich selber hinzufügt


//alt
$newEventID = IPS_CreateEvent(0);
IPS_SetEventTrigger ($newEventID, 1, $VarID);
IPS_SetEventScript ($newEventID, $IPS_SELF);
IPS_SetName ($newEventID, "ParentID: " . $InstanzID);
IPS_SetEventActive ($newEventID, true);

//neu
$newEventID = IPS_CreateEvent(0);
IPS_SetEventTrigger ($newEventID, 1, $VarID);
IPS_SetName ($newEventID, "ParentID: " . $InstanzID);
IPS_SetParent ($newEventID, $IPS_SELF);
IPS_SetEventActive ($newEventID, true);

Hier hat jetzt die Funktion „IPS_SetEventScript“ eine völlig andere Bedeutung.
Finde die Möglichkeit zwar gut, jetzt einfach dort einen PHP-Code hinterlegen zu können, allerdings das das aufzurufende Skript jetzt rein durch den Parent angegeben wird eher unpraktisch. Vorher konnte ich die Events irgendwo in meiner Hierarchie anlegen, jetzt ist dies nur noch direkt unterhalb des Skripts möglich.
Des weiteren gestaltet sich jetzt die Ermittlung natürlich auch anders, ob für die Variable ein Event existiert, was das aktuelle Skript triggert.
Unschön daran ist jetzt, das durch eine minimale Fehlbedienung (das Event wird aus versehen verschoben) ein ganz anderes Skript aufgerufen werden könnte.

Ich fand die Funktionalität wie sie vorher war schon gut.

Mal dann grob die Frage, warum man die „alten“ Funktionen nicht erst einmal als „deprecated“ markiert, damit man sich darauf einstellen kann das die Funktionen irgendwann flöten gehen, aber zumindest in ihrer Funktion erst ein mal noch das selbe tun.

2

Eine kurze Erklärung warum die Funktionen geändert/gelöscht wurden bzw. warum das Konzept der Events und der Aufruf der Skripte geändert wurde, würde mich schon mal interessieren. Vor allem ob man in Zukunft weiter mit solchen „drastischen“ Änderungen rechnen kann?

3

Änderungen können immer vorgenommen werden. Je nach Bedarf werden Funktionen geändert oder optimiert, wenn diese der Verbesserung der Konsistenz dienen. Beim Fall der Ereginisse war es einfach notwendig. (Sonst hätten wir es ja nicht gemacht, da wir uns der Tragweite durchaus bewusst sind)

Von deprecated Funktionen halte ich nichts. Wegfallen lassen darf man die dann ja im Prinzip nie, weil man die Mehrheit der User diese Funktion eh nie Austauschen wird.

Betroffen sind übrigens meistens nur LowLevel Funktionen die für einen Bruchteil der User relevant sind. (IPS_SetScriptEvent vielleicht die Ausnahme)

Zwischen den 2.x Releases sind bis jetzt keine weiteren Änderungen von Funktionen geplant. Zu einem 3.0 Release würde ich aber wieder damit rechnen. (Siehe auch Ankündigung der 2.0, dass die Funktionen der 1.0, die Namen annehmen, dies irgendwann nicht mehr tun werden. 3.0?)

Veraltete Funktionen müllen die API zu, die ohnehin schon Komplex genug ist.

paresy

4

Hi paresy,

erst einmal Danke für deine Ausführungen.

Das immer wieder etwas optimiert werden kann und auch soll ist mir klar.
Aber kannst du dir auch vorstellen, das ich mir als Anwender nach dem Update auf einmal vorkam, als wenn ich ins Auto einsteige, Gas und Bremse vertauscht ist und ich nur noch Rückwärts fahre?
Ein besserer Vergleich ist mir gerade nicht eingefallen :wink:

Darf man fragen was es mit den Änderungen bei den Ereignissen auf sich hatte, das diese Änderung notwendig gemacht hat? Evt. ist mir das Konzept noch nicht ganz bewußt, aber Events habe ich bisher einfach als einfachen Trigger gesehen, der ggf. Eingangsparameter hat und dann etwas anderes ausführt. Das war in meinem Fall im schön ein Skript, unabhängig davon wo sich in der Struktur das Event befindet. Das ist jetzt die Events die ein spezielles Skript triggern sollen, direkt unterhalb diesem anlegen muss ist mir jetzt so aufgefallen, ging mir aber aus den Upgradehinweisen („Ereignisse können direkt an Variablen/Instanzen erstellt werden“) nicht hervor. Außerdem erschließt sich mir der Sinn dahinter nicht.

Das Beispiel deprecated hatte ich aufgeführt, da man so dem „Entwickler“ zumindest die Möglichkeit gibt, die Funktionalität in einer Version sowohl mit der „alten“ Variante die demnächst dann wegfällt zu testen, als auch das testen der „neuen“ Funktionalität. Wer dann innerhalb von ein paar Releases nicht selbst umstellt hat dann Pech, aber die Möglichkeit beide zu nutzen um zu gucken ob noch alles läuft würde ich bevorzugen. So hat man es selber in der Hand und wird nicht überfahren. Das das eine API aufbläht ist mir bewußt, könnte ich in meinem Job die API so bestimmen wie ich das gerne hätte, wäre die auch um einiges schlanker, allerdings würden mir dann gewiss ein paar Kunden den Kopf abreißen, wenn ich die von einem auf das nächste Release wegfallen lasse :cool: