Hallo Rudi,
verstehe ich das richtig, dass der "Lademechanismus" für 99er-Module einzig und allein in der sub GlobalAttr() steckt und genau dann ausgeführt wird, wenn der modpath gesetzt wird?
Ich arbeite gerade an einer Möglichkeit, eigene 99_.*.pm Dateien in die configDB zu importieren und von dort zu laden. Grundsätzlich funktioniert das bei mir jetzt schon völlig problemlos. Ich wundere mich nur darüber, dass es so erstaunlich einfach zu implementieren sein könnte, wie ich das jetzt in der fhem.pl eingebaut habe:
elsif($name eq "modpath") {
return "modpath must point to a directory where the FHEM subdir is"
if(! -d "$val/FHEM");
my $modpath = "$val/FHEM";
opendir(DH, $modpath) || return "Can't read $modpath: $!";
push @INC, $modpath if(!grep(/\Q$modpath\E/, @INC));
$attr{global}{version} = $cvsid;
my $counter = 0;
+ if($attr{global}{configfile} eq 'configDB') {
+ Log 4, "loading 99ers from configDB";
+ $counter += cfgDB_Read99(undef);
+ }
Nach meinem Veständnis müsste ich allerdings auch noch eine Anpassung in CommandReload machen.
Zitatverstehe ich das richtig, dass der "Lademechanismus" für 99er-Module einzig und allein in der sub GlobalAttr() steckt und genau dann ausgeführt wird, wenn der modpath gesetzt wird?
Scheint mir auch so. Hab die Stelle seit Jahren nicht angefasst.
ZitatNach meinem Veständnis müsste ich allerdings auch noch eine Anpassung in CommandReload machen.
Das wird aber erst dann interessant, wenn man die Dateien auch "online" editieren kann.
Funktioniert über den Umweg Export -> Editieren -> Import jetzt schon. Aber für einen Automatismus, das in der FHEMWEB einfacher zu machen, fehlt mir momentan noch ein Plan, weil ich erst genau rausfinden muss, wie Du das mit dem "Save" beim "edit files" machst. Es ist halt - historisch bedingt - einfach nicht gekapselt genug, um sich da einfach reinzuhängen (das ist jetzt überhaupt kein Vorwurf!)
FW_fileList($) dazu zu bringen, in configDB gespeicherte Dateien mit anzuzeigen, ist jedenfalls kein Problem ;)
Das Speichern passiert in der FW_style, elsif($a[1] eq "save") Abschnitt, anpassen muesste einfach sein.
Ja, dazu fehlt mir noch das Gegenstück für die configDB, ausserdem brauch ich noch den Mechanismus, den Inhalt einer gewählten Datei aus der Datenbank zu lesen. (wobei ich die Stelle schon kenne, das ist ungefähr da, wo wir den codemirror ansetzen)
Eins nach dem anderen, ich komme da sicher nochmal mit ganz konkreten Fragen auf Dich zu.
Ich bin ja schon froh, dass ich meine RSS und holiday Dateien jetzt schonmal gesammelt in der Datenbank führen kann. Und dass das initiale Lesen der 99ers so problemlos funktionieren kann :)
Könnte man bei Gelegenheit sowas in die fhem.pl einbauen?
sub configDBUsed()
{ return ($attr{global}{configfile} eq 'configDB'); }
Das würde die Lesbarkeit mancher Codingstellen erhöhen und im Sourcecode übersichtlicher aussehen.
if (configDBUsed)
sieht irgendwie "schöner" aus als
if($attr{global}{configfile} eq 'configDB')
Vor allem es kapselt den String configDB.
Habs eingebaut in fhem.pl und in etwa 5 FHEM/*.pm Dateien.
wie? was? neue Funktion schon eingebaut? Super, danke :)
Mal eben aus den Tiefen der FHEMWEB wieder auftauchen, um Luft zu holen...
- FW_fileList = funktioniert
- FW_style list = funktioniert
- automatisches Lesen aus configDB in "Edit files" - funktioniert
- FW_style edit = funktioniert
- FW_style save = funktioniert theoretisch (d.h. ich weiss, wie ich es umsetze, aber ich hab heute keine Lust mehr)
- reload/rereadcfg = muss ich als nächstes drüber nachdenken, nicht nur für FHEMWEB sondern auch für fhem.pl
Alles in allem war es gar nicht so kompliziert wie befürchtet, man muss nur erstmal die Logik durchschauen. Das am meisten Verwirrende ist der Mischmasch aus den ganzen html-Texten die in FHEMWEB "geschrieben" werden und dem Coding dazwischen *lach*
- FW_style save = funktioniert (für save und save as)
- Das Reload muss ich in der fhem.pl einbauen, denn die FHEMWEB ruft ja auch nur die Funktion in der fhem.pl auf.
Falls von Interesse, habe ich hier die bei mir durchgeführten Änderungen in der FHEMWEB angehängt.
Das Einzige was noch fehlt (auskommentiert), ist der Aufruf des reload bei Datenbanknutzung. (gestrichen da obsolet)
Verbesserungsvorschläge gerne jederzeit hier.
Fertsch :)
Das Laden der 99_.*.pm-Dateien aus der configDB ist nun komplett in CommandReload enthalten. Wird der übergebene Dateiname nicht gefunden und die configDB ist aktiv, wird versucht, die Datei in der Datenbank zu finden. Im Erfolgsfall wird die Datei ins Dateisystem exportiert, und dem bewährten Evaluierungs- und Ladeprozess von fhem übergeben. Nach der Evaluierung wird die Datei im Dateisystem wieder gelöscht. Das war die einfachste Lösung, um nicht den ganzen Lademechanismus neu schreiben (und testen und bugfixen) zu müssen.
Beim Starten von fhem werden die 99_.*.pm Dateien wie bisher in der Funktion GlobalAttr() erstmalig geladen, indem zusätzlich zur Dateiliste der Module aus dem Dateisystem noch eine Dateiliste der in configDB vorhandenen 99_ Dateien auf identische Art und Weise (Aufruf von CommandReload) verarbeitet wird.
Beim Ändern einer Datei im Frontend, die aus der Datenbank gelesen wird, erfolgt das Speichern auch wieder in die Datenbank. Falls es sich bei der geänderten Datei um eine Moduldatei handelt, wird diese anschließend ebenfalls über "reload" neu geladen - identisch zur bisherigen Vorgehensweise.
Irgendwelche Einwände gegen dieses generische Vorgehen? Im Anhang befinden sich zwei diff files für fhem.pl und 01_FHEMWEB.pm
Nach umfangreichen Tests habe ich die Änderungen jetzt auch auf meinem produktiven fhem im Einsatz - bisher absolut problemlos.
Nächste Baustelle: Das gleiche für die gplot Files. Wobei das Lesen in 98_SVG.pm relativ simpel ist (vergleichbare Änderung wie in 95_holiday) aber für den gplot-Editor muss ich wohl wieder tief in die FHEMWEB hinabtauchen 8)
Zitat von: betateilchen am 21 April 2014, 14:54:57
Nächste Baustelle: Das gleiche für die gplot Files. Wobei das Lesen in 98_SVG.pm relativ simpel ist (vergleichbare Änderung wie in 95_holiday) aber für den gplot-Editor muss ich wohl wieder tief in die FHEMWEB hinabtauchen
Erledigt und im Testbetrieb erfolgreich im Einsatz. Das war doch einfacher als ich dachte und die FHEMWEB war erfreulicherweise (fast) nicht involviert :)
Aenderung in fhem.pl koennte ich uebernehmen, die Aenderung in 01_FHEMWEB.pm auch, bis auf das Loeschen eines Punktes in FW_pH. FW_pH ist viel zu generische, ich will da sowas nicht haben. Kannst Du das bitte anders loesen?
Hallo Rudi,
danke für Deine Bewertung. Ich habs geahnt... der Punkt war die Sache, die mir bei der Umsetzung am meisten Kopfzerbrechen gemacht hat.
Ok, ich werde über den Punkt heute abend nochmal intensiv nachdenken, vielleicht fällt mir etwas konformeres ein.
Hättest Du etwas dagegen, wenn ich den Punkt in FW_displayFileList entferne und dann so arbeite?
sub
FW_displayFileList($@)
{
my ($heading,@files)= @_;
my $hid = lc($heading);
$hid =~ s/[^A-Za-z]/_/g;
FW_pO "<div class=\"fileList $hid\">$heading</div>";
FW_pO "<table class=\"block fileList\">";
my $cfgDB = "";
my $row = 0;
foreach my $f (@files) {
$cfgDB = $f =~ s,\.$,,; # remove dot as last character (used to indicate configDB content)
$cfgDB = ($cfgDB) ? "X" : "-";
FW_pO "<tr class=\"" . ($row?"odd":"even") . "\">";
FW_pH "cmd=style edit $f $cfgDB", $f, 1;
FW_pO "</tr>";
$row = ($row+1)%2;
}
FW_pO "</table>";
FW_pO "<br>";
}
In FW_style() hätte ich damit in @a ein neues Element, das ich sowohl in "edit" als auch in "save" auswerten kann und die FW_pH() bliebe unangetastet.
Das ist schon mal begrenzter in der Wirkung, also gut :)
Kannst Du statt . und X was laengeres (.configDB o.ae.) als Suffix/Markierung waehlen, damit man die Links auch nach einem Jahr zuordnen kann?
Klar, kann ich machen, bin halt nur kein großer Freund von langen Strings in Quelltexten.
Ich baue heute abend nochmal patches, dann auch schon für/mit 98_SVG.pm
Zitat von: betateilchen am 22 April 2014, 11:45:33
Ich baue heute abend nochmal patches, dann auch schon für/mit 98_SVG.pm
wie versprochen: geändert, getestet, gedifft :)
Falls Du Dich mit dem Vertauschen der Listenblöcke styles und gplot anfreunden kannst, diese Änderung ist mir versehentlich ;) ;) auch mit reingerutscht.
Habs an wenigen Stellen leicht umformatiert, getestet und eingecheckt.
Danke schön :)
Ich bin grade noch auf ein Problem gestoßen - die Neuanlage über den Link "Create SVG plot" in der Detailansicht eine Logfiles funktioniert noch nicht richtig, das template File wird offenbar nicht gelesen. Grundsätzlich funktioniert das Anlegen des Plots trotzdem, die angezeigte Fehlermeldung ist eben nur erstmal verwirrend.
Muss ich mir genauer anschauen.
Gelöst - "set <name> copyGplotFile" hatte ich überhaupt nicht auf dem Schirm.
So klappts auch mit dem Create-Link:
Index: 98_SVG.pm
===================================================================
--- 98_SVG.pm (revision 5603)
+++ 98_SVG.pm (working copy)
@@ -99,13 +99,16 @@
$hash->{GPLOTFILE} . ":".
$hash->{LOGFILE};
- open(SFH, $srcName) || return "Can't open $srcName: $!";
- open(DFH, ">$dstName") || return "Can't open $dstName: $!";
- while(my $l = <SFH>) {
- print DFH $l;
+ if(configDBUsed()) { # copy template.gplot inside configDB
+ _cfgDB_Writefile($dstName,_cfgDB_Readfile($srcName));
+ } else {
+ open(SFH, $srcName) || return "Can't open $srcName: $!";
+ open(DFH, ">$dstName") || return "Can't open $dstName: $!";
+ while(my $l = <SFH>) {
+ print DFH $l;
+ }
+ close(SFH); close(DFH);
}
- close(SFH); close(DFH);
-
return undef;
}
Eingecheckt.
Ich finde es wird Zeit fuer ein readCfgFile/writeCfgFile in fhem.pl
Es aergert mich nur, dass ich nicht vorher auf die Idee gekommen bin.
Zitat von: rudolfkoenig am 23 April 2014, 12:50:12
Eingecheckt.
Danke.
Zitat von: rudolfkoenig am 23 April 2014, 12:50:12
Ich finde es wird Zeit fuer ein readCfgFile/writeCfgFile in fhem.pl
Zitat von: rudolfkoenig am 23 April 2014, 12:50:12
Es aergert mich nur, dass ich nicht vorher auf die Idee gekommen bin.
Rudi, nicht ärgern, ein lebendes Produkt wie fhem entwickelt sich einfach weiter und dann kommen solche "Leichen" eben irgendwann aus dem Keller wieder ans Tageslicht. Bisher kam ja auch niemand auf die Idee, alles was mit Konfiguration zu tun hat, in eine Datenbank zu schreiben.
Ich hätte das mit den Konfigurationsfiles ja auch gerne anders gelöst, aber aus Kompatibilitätsgründen heißen die Konfigurationsfiles in der Datenbank nun eben auch genau so wie im Dateisystem - inkl. Pfadangabe. Dafür ist es auf diese Weise für die User in der Anwendung aber völlig transparent geblieben.
Zitat von: rudolfkoenig am 23 April 2014, 12:50:12
Ich finde es wird Zeit fuer ein readCfgFile/writeCfgFile in fhem.pl
Es aergert mich nur, dass ich nicht vorher auf die Idee gekommen bin.
Das kannst Du doch jederzeit noch nachholen. Die meisten Stellen, an denen sowas gebraucht würde, haben wir doch inzwischen identifiziert und entsprechend vorbereitet :)
Falls Du das aber angehst, lass uns das bitte abstimmen, damit wir vereinheitlichen können, ob das Lesen einer Konfigurationsdatei einen String (mit \n getrennte Textzeilen) oder ein ein Array (mit den Konfigurationszeilen) zurückliefern soll.
Eine Baustelle habe ich noch, die ich im Zusammenhang mit configDB jetzt noch angehen muss: 98_update.pm
Wenn eine Datei per Update kommt, muss geprüft werden, ob die Datei "configDB-relevant" ist und entsprechend reagiert werden.
Wobei dabei auch noch Fallunterscheidungen zu treffen sind.
Beispiele:
- geänderte 99_myUtils.pm : diese Datei kann, darf, muss aber nicht in der configDB liegen, um zu funktionieren
- neue oder geänderte XYZ.gplot : diese Datei muss in der configDB liegen, um benutzt werden zu können.
Dazu werde ich eine entsprechend Funktion bauen, mit der das update-Modul einfach Dateinamen an configDB übergibt, und configDB wird entsprechend handeln und an update zurückmelden.
Wobei ich noch nicht sicher bin, ob ich das einzeln nach jedem get(file) machen soll oder ob update am Ende eine Namensliste übergibt - das wäre sicher perfomanter.
Ich hätte da noch eine klitzekleine Korrektur für die fhem.pl damit CommandVersion auch svnIds aus Moduldateien in der configDB finden kann.
Index: fhem.pl
===================================================================
--- fhem.pl (Revision 5640)
+++ fhem.pl (Arbeitskopie)
@@ -2435,7 +2435,12 @@
Log 4, "Looking for SVN Id in module $m";
my $fn = "$attr{global}{modpath}/FHEM/".$modules{$m}{ORDER}."_$m.pm";
if(!open(FH, $fn)) {
- push @ret, "$fn: $!";
+ my $ret = "$fn: $!";
+ if(configDBUsed()){
+ Log 4, "Looking for module $m in configDB to find SVN Id";
+ $ret = cfgDB_Fileversion($fn,$ret);
+ }
+ push @ret, $ret;
} else {
push @ret, map { chomp; $_ } grep(/# \$Id:/, <FH>);
}
eingecheckt
danke!