help (was: Templates in FHEM)

[rudolfkoenig]

in 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.

[Dr. Boris Neubert]

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

[betateilchen]

template ist eingecheckt.

Funktioniert aber nicht ohne weiteres für configDB Anwender, trotz Deiner Umstellung auf FileRead().

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.

[rudolfkoenig]

Funktioniert aber nicht ohne weiteres für configDB Anwender, trotz Deiner Umstellung auf FileRead().

Und warum nicht?

"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.

[Dr. Boris Neubert]

Funktioniert aber nicht ohne weiteres für configDB Anwender, trotz Deiner Umstellung auf FileRead().

Aha.

"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

Code Auswählen Erweitern

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 global

zeigt mir help weder version noch template. Lasse ich die FHEMWEB-Definition weg, wird das Modul nicht geladen mit

Code Auswählen Erweitern

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.

[betateilchen]

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

Code Auswählen Erweitern

 
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.

[betateilchen]

Mit dieser Änderung kann man das Modul dazu bringen,
bei configDB Nutzern zumindest einmal grundsätzlich zu funktionieren.

Code Auswählen Erweitern


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.

[betateilchen]

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)

[Dr. Boris Neubert]

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.

[Dr. Boris Neubert]

Mit dieser Änderung kann man das Modul dazu bringen,
bei configDB Nutzern zumindest einmal grundsätzlich zu funktionieren.

Eingecheckt!

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

[betateilchen]

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.

[Dr. Boris Neubert]

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?

[betateilchen]

Die Frage verstehe ich grade nicht.

[Dr. Boris Neubert]

Ich meinte, das CommandInclude auch mit Konfigurationsdateien arbeitet. CommandTemplate ist praktisch CommandInclude mit Parametersubstitution als Extra.

[betateilchen]

Bei der Migration muss sich configDB nicht um includes kümmern.