Bezeichner aus Wertelisten in Scripts verwenden

[Matsch]

Wie man den Bezeichnernamen eines Wertes aus einer Werteliste über den Index ermitteln kann, ist mir ja geläufig.
Wie aber ist es in umgekehrter Richtung?

Beim Programmieren von Scripts ist es für das Verständnis des Scripts wenig hilfreich, beim Zuweisen von Werten aus der Liste den Index anzugeben, weil der einem zunächst gar nichts sagt, was dahinter steckt. Besser wäre es, direkt die Bezeichner als Wert verwenden zu können.

Beispiel:
Eine Systemvariable "Tageszeit" vom Typ Werteliste mit den Werten "Nacht;Vormittag;Nachmittag;Abend"

Möchte ich die auf Nachmittag setzen, schreibe ich

Code: Alles auswählen

dom.GetObject(ID_SYSTEM_VARIABLES).Get("Tageszeit").State(2);

Lieber aber würde ich so eine Konstruktion benutzen:

Code: Alles auswählen

dom.GetObject(ID_SYSTEM_VARIABLES).Get("Tageszeit").State(Nachmittag);
! oder 
dom.GetObject(ID_SYSTEM_VARIABLES).Get("Tageszeit").State("Nachmittag");

Doch dazu müßte o.g. Vorgang umkehrbar sein. Hat jemand dafür eine Lösung oder geht es nur über die nichtssagenden Indizes?

[MichaelN]

Du kannst die Variablen mit sprechenden Namen anlegen und mit dem entsprechenden Wert belegen.

Also

Code: Alles auswählen

integer Nachmittag = 2;

usw

[Matsch]

Das macht die Sache nicht wirklich besser. Und ja, so mache ich das z.Z. aus Verzweiflung, bin aber damit nicht zufrieden.

Ist eine ziemliche Krücke, zumal man das ja bei jedem Script wiederholen muß.
Zudem ist es bezüglich der Softwarepflege ein Unding im Falle einer Änderung der Werteliste - aber das trifft ja auf die Verwendung von Indizes auch zu.

[Black]

wenn eine derartige Konstantenliste eingebunden werden soll und diese in mehreren Scripten verwendung finden soll, so bietet sich da
das #inc ab. Quasi ein Include.

Black

[Matsch]

Uff, das höre ich das erste Mal. Gibt's das nur vom Hören-Sagen oder auch irgendwo schriftliche Beiträge?

[Black]

Uff, das höre ich das erste Mal. Gibt's das nur vom Hören-Sagen oder auch irgendwo schriftliche Beiträge?

so direkt nicht.... zählt zu der Gattung der nicht unbedingt von EQ3 dokumentierten Befehle.
Ist aber nicht total geheim, die Verwendung findet sich auch bei EQ3 in der Firmware.

beispiel ist in /www/rega/esp/side.fn welche eine Include datei side.inc einbindet. Dort könntest du nachlesen
praktisches kleines Beispiel:

wie nehmen folgende kleine Zeilen

Code: Alles auswählen

<%
system.Exec ("logger -t LOGGERNAME -p user.debug [IncludeRun]");  
%>

speichern die als include.inc ab und spielen die via filezilla ins verzeichnis /usr/local.

im sdv z,b. schreiben wir kleines Testscript:

Code: Alles auswählen

WriteLine ("aaa");
#inc ("../../etc/config/../../include.inc");   

die Ausführung bringt nun:

Code: Alles auswählen

------------------------------- Scriptausgabe -------------------------------
aaa
------------------------------ Script Variablen -----------------------------
--------------------------------- SystemLog ---------------------------------
Apr 19 21:30:53 SpieleSystem user.debug LOGGERNAME: [IncludeRun]

er hat also das include geladen und darin den logger ausgeführt.
soweit hübsch, nun das Kleingedruckte:
1. das include muss in <% scriptcode %> gepackt sein
2. das #inc darf nicht der erste Befehl des scriptes sein
3. Intern würde der Scriptparser mit "/www/rega" präfixen. könenn wir nicht brauchen. Deswegen das Directory Traversal ../../etc/config/../../ welches dann auf /user/local verweist, wohin wir auch das inc hingeladen haben
4. die rega cashed #inc und call. heisst: beim ersten aufruf legt sich dei rega den inhalt von include.inc in ihren cache. beim nächsten mal wird immer aus dem cache geholt. bedeutet: änderst du nun das .inc file und lädst das hoch, führst das script aus dann:überraschung, es funktioniert immer noch so wie vor der Änderung. Auch logisch, weil dies steht auch im cache und deine Änderung ist der Rega sowas von egal. Bedeutet: Wenn du ein Include oder eine Funtion änderst, musst du den cache killen.am sichersten geht das mit rega stop und rega restart. dann übernimmt er deine änderung.
5. der SDV kann das <% und %> "noch" nicht korrekt darstellen. Known Issue. ist aber ausser mir noch nicht soooo vielen aufgefallen.

noch Fragen ? kein Problem

Black

[Matsch]

zählt zu der Gattung der nicht unbedingt von EQ3 dokumentierten Befehle.

Davon gibt's ja nicht so viele ....

noch Fragen ?

Nein, wenn die Lösung sooo einfach ist

Du hast dir wieder mal sehr viel Mühe gemacht um mir zu zeigen, dass es wohl keine vernünftige, elegante und einfache Lösung für mein Anliegen gibt.
Homematic halt.

[MichaelN]

Programmieren besteht halt oft aus Organisation, Dokumentation und Fleißarbeit. Und daher finde ich es nicht sonderlich abschreckend einen Block an Konstanten zu pflegen und in das jeweilige Programm einzufügen. Setz einen aussagekräftigen Kommentar mit Versionierung dazu und dann kannst Du mit Blacks SDV bequem alle ggf. zu ändernden Skripte suchen und anpassen.

[Matsch]

Und das aus deinem Munde? Du weißt doch selbst, wie eine Software aussehen sollte, damit im Zuge einer Pflege möglichst wenig neue Fehler hineinkommen.

... einen Block an Konstanten zu pflegen ...

Wenn es denn mal wirklich Konstanten geben würde ...