Zitatin Zeile 369 steht die Hilfe zu restore, was aber auch ein eigenes Modul ist.
Stimmt, bin auch nicht ganz sicher, ob es reingehoert.
"help" liefert Hilfe fuer die Befehle, die in fhem.pl definiert sind, oder schon geladen sind. Befehle, die im "Zweifel" wichtig sind, wie update und restore wollte ich dem Benutzer nicht vorenthalten. Ich lasse aber mit mir diskutieren.
Zitat von: rudolfkoenig am 12 März 2017, 10:33:00
Stimmt, bin auch nicht ganz sicher, ob es reingehoert.
"help" liefert Hilfe fuer die Befehle, die in fhem.pl definiert sind, oder schon geladen sind. Befehle, die im "Zweifel" wichtig sind, wie update und restore wollte ich dem Benutzer nicht vorenthalten. Ich lasse aber mit mir diskutieren.
Keine Diskussion sondern Auffrischung der Erinnerungen. Hatten wir nicht mal vor einiger Zeit schon eine Diskussion, wie man mit dem Henne-Ei-Problem umgeht, dass man Hilfetexte aus und Informationen zu Modulen nur anzeigen kann, wenn man diese geladen hat, wozu fhem.pl wieder wissen muss, dass es sie gibt? Finde diese Diskussion nicht mehr. Wie ging die aus?
Alternativ die Hilfe wie die commandref automatisch aus dem Anhang zum Quelltext generieren lassen. Dann können
alle Befehle in Module und es werden dennoch alle Befehle angezeigt.
Ich werde off-topic.
template ist eingecheckt.
Schönen Sonntag!
Boris
Zitat von: Dr. Boris Neubert am 12 März 2017, 17:14:18
template ist eingecheckt.
Funktioniert aber nicht ohne weiteres für configDB Anwender, trotz Deiner Umstellung auf FileRead().
Zitat von: Dr. Boris Neubert am 12 März 2017, 17:14:18
wie man mit dem Henne-Ei-Problem umgeht, dass man Hilfetexte aus und Informationen zu Modulen nur anzeigen kann, wenn man diese geladen hat,
"help" zeigt den commandref-Hilfetext zu Modulen an, egal ob das Modul geladen ist oder nicht. Und das ist schon ziemlich lange so.
ZitatFunktioniert aber nicht ohne weiteres für configDB Anwender, trotz Deiner Umstellung auf FileRead().
Und warum nicht?
Zitat"help" zeigt den commandref-Hilfetext zu Modulen an, egal ob das Modul geladen ist oder nicht.
Jein. Ich meinte help ohne Argument: da kommt z.Bsp. version erst, wenn man version aufgerufen hat. "help version" funktioniert allerdings auch vorher.
Zitat von: betateilchen am 12 März 2017, 17:47:25
Funktioniert aber nicht ohne weiteres für configDB Anwender, trotz Deiner Umstellung auf FileRead().
Aha.
Zitat
"help" zeigt den commandref-Hilfetext zu Modulen an, egal ob das Modul geladen ist oder nicht. Und das ist schon ziemlich lange so.
In einer quasi-leeren Konfiguration
attr global statefile /users/neubert/Development/Perl/fhem-data/fhem.save
attr global verbose 5
attr global port 7072 global
attr global modpath /users/neubert/Development/Perl/fhem
attr global logdir /users/neubert/Development/Perl/fhem-data
define ui FHEMWEB 8083 globalzeigt mir help weder version noch template. Lasse ich die FHEMWEB-Definition weg, wird das Modul nicht geladen mit
2017.03.12 18:23:36 5: Loading /users/neubert/Development/Perl/fhem/FHEM/98_help.pm
2017.03.12 18:23:36 1: reload: Error:Modul 98_help deactivated:
Global symbol "$FW_ME" requires explicit package name (did you forget to declare "my $FW_ME"?) at /users/neubert/Development/Perl/fhem/FHEM/98_help.pm line 116.
2017.03.12 18:23:36 0: Global symbol "$FW_ME" requires explicit package name (did you forget to declare "my $FW_ME"?) at /users/neubert/Development/Perl/fhem/FHEM/98_help.pm line 116.
Zitat von: Dr. Boris Neubert am 12 März 2017, 18:23:49
In einer quasi-leeren Konfiguration
zeigt mir help weder version noch template. Lasse ich die FHEMWEB-Definition weg, wird das Modul nicht geladen mit
Dann stimmt aber in Deiner Konfiguration etwas anderes nicht. Vorhin habe ich mir "help template" durchgelesen, ohne das Modul geladen zu haben - und es wurde deshalb auch logischerweise nicht in version angezeigt.
Auch "help version" liefert den Hilfetext zu version - genau wie es soll - ohne das Modul zu laden.
Vielleicht hätte ich vorhin präziser formulieren sollen:
"help <modulName|deviceName>" zeigt den commandref-Hilfetext zu Modulen an, egal ob das Modul geladen ist oder nicht.
Dafür bin ich jetzt nochmal ganz präzise:
Dein 98_template.pm funktioniert für configDB Nutzer überhaupt nicht, was daran liegt, dass eine Prüfung
return ($err, undef, undef, undef) if(defined($err));
ohne Prüfung auf einen Inhalt von $err in diesem Szenario immer zu einem return führt, weil configDB->FileRead() immer ein definiertes $err zurückliefert. Es ist eben im Erfolgsfall einfach leer.
Außerdem gibt es noch ein paar andere Tücken:
- bei configDB Nutzern wird das angegebenen template file zwingend aus der Datenbank gelesen. Es muss also erstmal dort angelegt bzw. dorthin importiert werden. Auf diese Tatsache sollte man in der Doku hinweisen.
- Wenn das file in der Datenbank liegt, ist eine einfache Änderung nicht ohne größeren Aufwand möglich. Deshalb sollten die template files am besten unter "Edit files" angezeigt werden. Um das zu erreichen, muss entweder eine feste Dateieendung bestimmt werden und FHEMWEB muss entsprechend angepaßt werden, um die Dateien zum Editieren anzuzeigen und auch die entsprechende Pfadangabe ermitteln zu können. Alternativ kann das der Anwender über das Attribut editFileList seiner FHEMWEB Instanz steuern. Darauf sollte man in der Doku hinweisen.
- Bei einer Migration von fhem.cfg zu configDB mittels "configdb migrate" werden die Templates nicht berücksichtigt. Das kann ich zwar gerne in die configDB Migration einbauen, aber dazu sollte für die template files eine feste Dateiendung vorgegeben werden und der Speicherort (analog zu .template, .holiday usw) in ./FHEM sein.
Mit dieser Änderung kann man das Modul dazu bringen,
bei configDB Nutzern zumindest einmal grundsätzlich zu funktionieren.
Index: 98_template.pm
===================================================================
--- 98_template.pm (Revision 13685)
+++ 98_template.pm (Arbeitskopie)
@@ -16,7 +16,7 @@
# load template from file
my ($err, @result)= FileRead($filename);
- return ($err, undef, undef, undef) if(defined($err));
+ return ($err, undef, undef, undef) if(defined($err) && $err ne "");
# remove trailing newlines and empty/whitespace lines
@result= grep /\S/, map { s/\r?\n$//; $_ } @result;
Die anderen aufgeführten Punkte aus meinem letzten Beitrag sollten allerdings auch noch überdacht werden.
Zitat von: rudolfkoenig am 12 März 2017, 18:20:38
Jein. Ich meinte help ohne Argument: da kommt z.Bsp. version erst, wenn man version aufgerufen hat. "help version" funktioniert allerdings auch vorher.
Das "Problem" kommt einfach daher, dass bis heute bezüglich der CommandXxxx() keine Einheitlichkeit besteht.
Wenn man alle Commands in eigene Moduldateien auslagert, wäre das Thema wahrscheinlich ziemlich einfach abzuhandeln.
Wenn alle Command-Module nämlich intern als solche gekennzeichnet sind, läßt sich auch für "help" ohne Parameter eine entsprechende Liste erzeugen (so wie es commandref_join ja auch tut)
Zitat von: betateilchen am 12 März 2017, 19:11:05
Wenn man alle Commands in eigene Moduldateien auslagert, wäre das Thema wahrscheinlich ziemlich einfach abzuhandeln.
Wenn alle Command-Module nämlich intern als solche gekennzeichnet sind, läßt sich auch für "help" ohne Parameter eine entsprechende Liste erzeugen (so wie es commandref_join ja auch tut)
Zustimmung.
Zitat von: betateilchen am 12 März 2017, 19:03:50
Mit dieser Änderung kann man das Modul dazu bringen,
bei configDB Nutzern zumindest einmal grundsätzlich zu funktionieren.
Eingecheckt!
Zitat
Die anderen aufgeführten Punkte aus meinem letzten Beitrag sollten allerdings auch noch überdacht werden.
Nicht mehr dieses Wochenende.
Ein Punkt, der mich ann FHEM schon lange stört, ist die Vermischung von Konfiguration und Programm. Meiner Meinung nach dürfte ein Anwender weder im Unterverzeichnis FHEM noch in gplot was schreiben. Ein Ausweg ist configDB. Ein anderer wäre es, logs, Konfigurationen (.conf, .holiday, .templ, ...), .gplot-Dateien und was einem noch so einfällt, in eine separate Verzeichnisstruktur auslagern zu können/müssen. attr global logdir ... ist ein guter Weg. Mit weiteren solchen globalen Attributen wüsste die Erstmigration in die configDB auch, wo sie suchen müsste.
Grüße
Boris
Zitat von: Dr. Boris Neubert am 12 März 2017, 19:23:58
Mit weiteren solchen globalen Attributen wüsste die Erstmigration in die configDB auch, wo sie suchen müsste.
Normalerweise entnimmt die Migration solche Informationen aus den Internals, die von bestimmten Modulen angelegt werden,
bei 02_RSS.pm z.B. das Internal LAYOUTFILE
bei 98_SVG.pm z.B. das Internal GPLOTFILE
Dabei ist eigentlich völlig egal, wo das File liegt. Es werden auch nur die Dateien migriert, die auch tatsächlich in Gebrauch sind.
Aber Dein 98_template ist m.W. das erste Command-Modul, das mit Konfigurationsdateien arbeitet, deshalb gibt es da keine Internals, die man auswerten könnte.
Zitat von: betateilchen am 12 März 2017, 19:32:29
Aber Dein 98_template ist m.W. das erste Command-Modul, das mit Konfigurationsdateien arbeitet, deshalb gibt es da keine Internals, die man auswerten könnte.
Wie machst Du es bei include?
Die Frage verstehe ich grade nicht.
Ich meinte, das CommandInclude auch mit Konfigurationsdateien arbeitet. CommandTemplate ist praktisch CommandInclude mit Parametersubstitution als Extra.
Bei der Migration muss sich configDB nicht um includes kümmern.
Zitat von: betateilchen am 12 März 2017, 19:11:05
Wenn alle Command-Module nämlich intern als solche gekennzeichnet sind, läßt sich auch für "help" ohne Parameter eine entsprechende Liste erzeugen (so wie es commandref_join ja auch tut)
Ich bin jetzt testweise einen anderen Weg gegangen. Eben habe ich eine Modulversion von 98_help.pm eingecheckt, die commands zumindest in der Liste aufführt, auch wenn das Modul selbst noch nicht geladen ist. In diesem Fall erscheint ein Hinweis, dass mit "help <name>" mehr Infos zu bekommen sind.
(siehe screenshot). Sobald der Befehl dann einmal ausgeführt wurde, wird in der Liste auch der Hilfetext aus der Moduldatei angezeigt.
Wenn man die hierfür in 98_help.pm neu eingebaute Funktion cref_fill_list() (die weitgehend aus commandref_join.pl kopiert wurde) in die fhem.pl übernehmen und beim Systemstart aufrufen würde, wäre der erste Aufruf von "help" erheblich schneller (und nicht blockierend).
sub cref_fill_list(){
my %mods;
my %modIdx;
my @modDir = ("FHEM");
foreach my $modDir (@modDir) {
opendir(DH, $modDir) || die "Cant open $modDir: $!\n";
while(my $l = readdir DH) {
next if($l !~ m/^\d\d_.*\.pm$/);
my $of = $l;
$l =~ s/.pm$//;
$l =~ s/^[0-9][0-9]_//;
$mods{$l} = "$modDir/$of";
$modIdx{$l} = "device";
open(MOD, "$modDir/$of") || die("Cant open $modDir/$l");
while(my $cl = <MOD>) {
if($cl =~ m/^=item\s+(helper|command|device)/) {
$modIdx{$l} = $1;
last;
}
}
close(MOD);
}
}
foreach my $mod (sort keys %mods) {
my %h = ( Fn => undef,
Hlp => "Command $mod not loaded. Use \"help $mod\" for more help" );
$cmds{$mod} = \%h if ( ($modIdx{$mod} eq "command") && !(defined($cmds{$mod})) );
}
}