[patch] 91_eventTypes.pm - generisches Lesen/Schreiben

[betateilchen]

Mit configDB und fhem.cfg hier erfolgreich getestet.

Trotzdem bitte ich darum, dass nochmal jemand mit fhem.cfg testet. Danke.

[rudolfkoenig]

Habs eingecheckt. Muss bei FileWrite an den Zeilen ein \n dranhaengen. Ich glaube das ist ein Fehler im Konzept, hatte aber kein Bock es jetzt ueberall umzubauen, vorallem sollte es mit dir abgestimmt sein.

[betateilchen]

ja, über das \n müssen wir uns dringend unterhalten.

Das hat mir schon eine Menge Kopfzerbrechen bereitet und letztendlich dazu geführt, dass ich in configDB beim Lesen/Schreiben nun schon wieder fallbezogene Unterscheidungen machen muss (z.B. bei den gplot Files!) damit alles korrekt funktioniert - das hat mit generisch schon wieder nichts mehr zu tun.

Das Schlimme ist, dass jedes Modul "seine" Dateien anders handhabt.

Mein angestrebtes Ziel wäre, ein Array komplett OHNE \n am jeweiligen Elementende zu Lesen und zu Schreiben.

[rudolfkoenig]

Meins natuerlich auch, wir muessen es nur koordiniert angehen.
Vorschlag: du haengst hier eine "\n" freie Version von "configDB.pm & co" an, was ich mit meinen Aenderungen gemeinsam einchecke. Passiert voraussichtlich erst morgen oder uebermorgen.

[betateilchen]

Du  kannst Deine Änderungen einchecken, wann immer Du möchtest. configDB geht jetzt schon davon aus dass die Daten ohne \n am Ende zum Schreiben geliefert werden, mit Ausnahme der gplot-Files und der von Dir festgestellten Problematik bei eventTypes funktioniert das auch schon überall.

Die Rückgaben von FileRead aus configDB sind schon jetzt immer ohne explizites \n es sei denn, die beim Schreiben angelieferten Daten enthielten bereits \n am Elementende, dann wird das natürlich auch wieder zurückgeliefert. Und genau das sollte nicht sein - kein Modul sollte Arrayelemente mit \n am Ende zum Schreiben anliefern.

[betateilchen]

Habs eingecheckt. Muss bei FileWrite an den Zeilen ein \n dranhaengen.

Das von Dir angehängte \n führt übrigens dazu, dass mein patch für 91_eventTypes nicht mehr korrekt funktioniert.

Genauer gesagt: jede zweite Zeile ist leer und wird beim Einlesen als "bogus line" angemeckert.

Code Auswählen Erweitern



1 Logfile reopen

2 blatest rereadcfg

4 eventTypes flush

10 gds _dataSource: Quelle: Deutscher Wetterdienst

4 gds active

3 gds c_altitude: .*

3 gds c_nextUpdate: Fri May .* .*:.*:.* .*

3 gds c_pressure-nn: .*

3 gds c_rain1h: .*

3 gds c_stationName: Düsseldorf-Flh.

3 gds c_temperature: .*

3 gds c_weather: gering bewölkt

3 gds c_windDir: O



Code Auswählen Erweitern



2014.05.23 22:31:04 2: eventTypes: ./log/eventTypes.txt: bogus line
2014.05.23 22:31:04 2: eventTypes: ./log/eventTypes.txt: bogus line
2014.05.23 22:31:04 2: eventTypes: ./log/eventTypes.txt: bogus line
2014.05.23 22:31:04 2: eventTypes: ./log/eventTypes.txt: bogus line
2014.05.23 22:31:04 2: eventTypes: ./log/eventTypes.txt: bogus line
2014.05.23 22:31:04 2: eventTypes: ./log/eventTypes.txt: bogus line



[rudolfkoenig]

Habs in fhem.pl und in meinen Modulen (holiday, eventTypes, FHEMWEB & SVG) geaendert, evtl. ist noch DbLog und RSS betroffen.
Kannst Du bitte pruefen, ob wir in FHEMWEB auf die configDB Sonderbehandlung verzichten koennen?
Das Problem mit eventTypes sollte damit auch verschwunden sein.

[betateilchen]

Habs in fhem.pl und in meinen Modulen (holiday, eventTypes, FHEMWEB & SVG) geaendert,

danke.

evtl. ist noch DbLog und RSS betroffen.

Ich schau mir die beiden Module mal an.

Kannst Du bitte pruefen, ob wir in FHEMWEB auf die configDB Sonderbehandlung verzichten koennen?

Auch das werde ich mir anschauen.

Könntest Du als "Chef" bei Gelegenheit die Verwendung der generischen Funktionen irgendwo so beschreiben, dass alle Entwickler das mitbekommen und künftig nicht immer noch mehr Module entstehen, die eigene Lese-/Schreibroutinen enthalten (wie z.B. jetzt wieder bei readingsHistory passiert). Der ursprüngliche Thread zu dem Thema scheint mir irgendwie nicht wirklich ernstgenommen worden zu sein.

[betateilchen]

Kannst Du bitte pruefen, ob wir in FHEMWEB auf die configDB Sonderbehandlung verzichten koennen?

Hallo Rudi,

auf die Sonderbehandlung können wir nicht verzichten, da bei weitem nicht alle Dateien in der configDB liegen und ich für jede in FHEMWEB zur Bearbeitung angebotene Datei eine Unterscheidung brauche, woher sie kommt damit sie auch wieder an die richtige Stelle zurückgeschrieben werden kann.

Beispiel (configDB Nutzung vorausgesetzt):

• 99_Utils.pm kann im Dateisystem liegen
• 99_myUtils.pm kann aber auf dem gleichen System in der Datenbank liegen
• .gplot files werden generell aus der Datenbank verwendet
• .css/.svg files werden generell aus dem Dateisystem verwendet

Für $FW_cssdir und $FW_gplotdir könnte man eventuell etwas vereinfachen, aber für 99_.*Utils.*pm Dateien in $MW_dir fällt mir noch keine plausible Lösung ein.

Ansatzpunkt für eine Vereinfachung sehe ich aktuell in FW_fileNameToPath() - mit Ausnahme der genannten Problemdateien.

[betateilchen]

FHEMWEB bräuchte in FileRead() und FileWrite() einen zusätzlichen optionalen Aufrufparameter, um die "Automatik" übersteuern zu können *grübel*

evtl. ist noch DbLog und RSS betroffen.

Testergebnisse - sieht alles sehr gut aus:

• DbLog und RSS funktionieren mit configDB nach der Änderung problemlos
• Die gplot-Dateien werden ohne zusätzliche Leerzeilen geschrieben
• Die eventTypes werden ohne zusätzliche Leerzeilen geschrieben