perlSyntaxCheck

[rudolfkoenig]

Ich habe ein global Attribut perlSyntaxCheck eingefuehrt, um eine Syntax-Pruefung beim Erstellen bzw. Modifizieren von Kommandos wie at/notify duerchfuehren zu koennen. Es waere nett, wenn ich Feedback kriegen wuerde, da ich evtl. was uebersehen habe.

Die Pruefung wird nur beim gesetzten Attribut, nach FHEM-Start durchgefuehrt, d.h. bei einem define/modify, was nach FHEM-Start abgesetzt wurde. Ich habe fhemweb.js so modifiziert, dass beim Aendern einer Definition im Detailfenster die Fehlermeldung im Dialog erscheint.

Falls weitere Module es verwenden moechten:

Code Auswählen Erweitern

  my $err = perlSyntaxCheck($command, %specials);
  return $err if($err);

wobei %specials ein mit Dummy-Werten ausgefuelltes Hash ist, was EvalSpecials bekommt.
Beispiel mit EvalSpecials ist 91_notify.pm, Beispiel ohne EvalSpecials ist 90_at.pm.

[justme1968]

ist es absicht das es erst bei featurelevel >5.7 automatisch aktiv wird statt bei >= 5.7?

[rudolfkoenig]

Yepp, sonst waere es ab sofort aktiv, und das ist mir noch zu "heiss".

[justme1968]

schade

gleich noch etwas: ich habe gerade geschaut ob ich das nicht auch für die attribute von readingsGroup und readingsProxy verwende. hier steht meist auch perl code. das FW_inlineModify modifiziert aber nur den input im edit div. spricht etwas dagegen auch das attribut input feld mit zu ändern?

[rudolfkoenig]

Nur der Test-Aufwand.

[justme1968]

mal unabhängig vom testen ... mit einem patch der folgen art geht die syntaxprüfung mit dem popup auch bei attributen:

Code Auswählen Erweitern

Index: 01_FHEMWEB.pm
===================================================================
--- 01_FHEMWEB.pm (revision 11184)
+++ 01_FHEMWEB.pm (working copy)
@@ -1137,6 +1137,7 @@
   $selEl = "room" if($list =~ m/room:/);
   $list =~ s/"/"/g;

+  my $psc = AttrVal("global", "perlSyntaxCheck", ($featurelevel>5.7) ? 1 : 0);
   my $ret ="";
   $ret .= "<div class='makeSelect' dev=\"$d\" cmd=\"$cmd\" list=\"$list\">";
   $ret .= "<form method=\"$FW_formmethod\" ".
@@ -1144,7 +1145,8 @@
   $ret .= FW_hidden("detail", $d);
   $ret .= FW_hidden("fwcsrf", $defs{$FW_wname}{CSRFTOKEN}) if($FW_CSRF);
   $ret .= FW_hidden("dev.$cmd$d", $d.($param ? " $param":""));
-  $ret .= FW_submit("cmd.$cmd$d", $cmd, $cmd);
+  $ret .= FW_submit("cmd.$cmd$d", $cmd, $cmd.($psc?" psc":""));
   $ret .= "<div class=\"$cmd downText\">&nbsp;$d&nbsp;".
                 ($param ? "&nbsp;$param":"")."</div>";
   $ret .= FW_select("sel_$cmd$d","arg.$cmd$d",\@al, $selEl, $cmd);


Code Auswählen Erweitern

Index: fhemweb.js
===================================================================
--- fhemweb.js (revision 11184)
+++ fhemweb.js (working copy)
@@ -460,10 +460,19 @@
function
FW_inlineModify()       // Do not generate a new HTML page upon pressing modify
{
-  $("div#edit input.psc[type=submit]").click(function(e){
+  $("div input.psc[type=submit]").click(function(e){
     e.preventDefault();
     var newDef = $(this).closest("form").find("textarea").val();
     var cmd = $(this).attr("name")+"="+$(this).attr("value")+" "+newDef;
+    if( newDef == undefined ) {
+      var div = $(this).closest("div.makeSelect");
+      var devName = $(div).attr("dev"),
+          cmd = $(div).attr("cmd");
+      var sel = $(this).closest("form").find("select");
+      var arg = $(sel).val();
+      newDef = $(this).closest("form").find("input:text").val();
+      cmd = $(this).attr("name")+"="+cmd+" "+devName+" "+arg+" "+newDef;
+    }
     FW_cmd(FW_root+"?"+encodeURIComponent(cmd)+"&XHR=1", function(resp){
       if(resp)
         return FW_okDialog(resp);

das problem das noch bleibt ist das die attribute nicht per longpoll aktualisiert werden. d.h. man müsste noch die seite refreshen oder den longpoll update für attribute einbauen. das event gibt es ja inzwischen.




mir ist beim testen noch ausgefallen das eine fehlende schliessende } nicht als fehler erkannt wird. ich weiss das liegt an der {...} prüfung und ich habe auch keine bessere idee, ich vermute aber das es ein recht häufiger fehler ist. vermutlich gilt das gleiche auch führende und folgende newlines oder tabs. da könnte man die regex erweitern.


es gibt glaube ich noch irgend wo ein timing problem oder eine race condition in verbindung mit codemiror:
- nach dem editieren bekomme ich keine meldung obwohl ich gerade einen fehler eingebaut habe
- die DEF zeile zeigt mir noch die alte version an

das ganze ist mir auch umgekehrt passiert:
- die DEF zeile hat einen fehler,
- wenn ich per fhemweb korrigiere ist nach dem klick auf modify immer noch die fehlerhafte version in der DEF zeile

es gibt keine javascript fehler.

[Benni]

Hallo Rudi,

ich habe eben mal auf meinen beiden Instanzen getestet.

Auf meiner Produktiv-Instanz (läuft mit configDB) erhalte ich gar keine Meldung, egal ob das notify korrekte oder Fehlerhafte Syntax enthält. Der DEF-Bereich bleibt unverändert (leer). Wenn ich erneut auf das DEF klicke ist aber der zuvor eingegebene Code da.

Auf meiner Entwicklungs- und Testinstanz erhalte ich zwar Fehlermeldungen, aber die erscheinen nicht in einem separaten Dialog, sondern direkt auf der Seite. Auch hier bleibt der DEF-Bereich unverändert.

Getestet habe ich wie folgt:

Code Auswählen Erweitern


define nySyntaxCheck notify nySyntaxCheck {}


Wie erwartet: keine Meldungen auf keiner der beiden Instanzen.

danach über Klick auf DEF den Inhalt wie folgt abgeändert:

Code Auswählen Erweitern


... {
    my $blah='';
}


per Klick modify nySyntaxCheck

- keine Meldung. DEF-Bereich in der Detailansicht bleibt leer (in der Produktiv-Instanz)
- keine Meldung. DEF-Bereich in der Detailansicht enthält korrekten Code (in der Test-Instanz)

nochmal editiert per Klick auf DEF und wie folgt geändert:

Code Auswählen Erweitern


... {
    my $blah='';
    my $blubb='' if(t=blau);
}


- keine Meldung. DEF-Bereich in der Detailansicht bleibt leer (in der Produktiv-Instanz)
- Nachfolgende Ausgabe von Meldungen im selben Fenster ohne Popup. DEF-Bereich in der Detailansicht bleibt unverändert (in der Test-Instanz):

Can't modify constant item in scalar assignment at (eval 170) line 3, near "blau)"
Bareword "blau" not allowed while "strict subs" in use at (eval 170) line 3.
Bareword "t" not allowed while "strict subs" in use at (eval 170) line 3.

Dazu erscheint bei mir im Logfile außerdem folgendes:

2016.04.04 20:20:07 1: PERL WARNING: Found = in conditional, should be == at (eval 169) line 3.
2016.04.04 20:20:07 3: eval: my $EVTPART4='5';my $EVTPART13='4';my $EVTPART10='1';my $EVTPART6='7';my $EVTPART11='2';my $EVENT='1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0';my $EVTPART20='1';my $EVTPART25='6';my $EVTPART19='0';my $EVTPART2='3';my $NAME='nySyntaxCheck';my $EVTPART14='5';my $EVTPART17='8';my $EVTPART23='4';my $EVTPART8='9';my $EVTPART7='8';my $EVTPART21='2';my $EVTPART5='6';my $EVTPART16='7';my $EVTPART0='1';my $EVTPART27='8';my $EVTPART22='3';my $EVTPART9='0';my $EVTPART3='4';my $EVTPART28='9';my $EVTPART1='2';my $EVTPART12='3';my $EVTPART24='5';my $EVTPART29='0';my $EVTPART18='9';my $TYPE='nySyntaxCheck';my $SELF='nySyntaxCheck';my $EVTPART15='6';my $EVTPART26='7';{return undef;; {
   my $blah='';;
   my $blubb='' if(t=blau);;
}}
2016.04.04 20:31:28 1: PERL WARNING: Found = in conditional, should be == at (eval 170) line 3.
2016.04.04 20:31:28 3: eval: my $EVTPART4='5';my $EVTPART13='4';my $EVTPART10='1';my $EVTPART6='7';my $EVTPART11='2';my $EVENT='1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0';my $EVTPART20='1';my $EVTPART25='6';my $EVTPART19='0';my $EVTPART2='3';my $NAME='nySyntaxCheck';my $EVTPART14='5';my $EVTPART17='8';my $EVTPART23='4';my $EVTPART8='9';my $EVTPART7='8';my $EVTPART21='2';my $EVTPART5='6';my $EVTPART16='7';my $EVTPART0='1';my $EVTPART27='8';my $EVTPART22='3';my $EVTPART9='0';my $EVTPART3='4';my $EVTPART28='9';my $EVTPART1='2';my $EVTPART12='3';my $EVTPART24='5';my $EVTPART29='0';my $EVTPART18='9';my $TYPE='nySyntaxCheck';my $SELF='nySyntaxCheck';my $EVTPART15='6';my $EVTPART26='7';{return undef;; {
   my $blah='';;
   my $blubb='' if(t=blau);;
}}

Beide Instanzen laufen mit dem FHEM-Update von heute.
Getestet habe ich mit Chrome-Browser.

Ich habe eben auch nochmal mit Safari getestet. Damit erhalte ich auf beiden Instanzen identisches Verhalten, nämlich so wie im vorangegangenen Test für die Produktiv-Instanz beschrieben.

Gruß Benni.

[rudolfkoenig]

mal unabhängig vom testen (https://forum.fhem.de/Smileys/default/smiley.gif)

Der Haken mit dem Patch ist:
- patch mag ihn nicht (malformed patch), musste ihn per Hand eingeben
- ohne die Attribut-Updates ist es fuer die Benutzer (== mich) sehr verwirrend. Kommt also erst dann rein, wenn wir Attribut-Updates koennen. FW_inlineModify koennte das auch uebernehmen, aber dann muss die leere Huelle der Attribut-Tabelle vorliegen, falls ein Geraet noch kein Attribut hat. Ich schau es mir demnaechst an, falls du nicht frueher dazu kommst.

eine fehlende schliessende } nicht als fehler erkannt wird

Ab jetzt schon. Es gibt keinen FHEM Befehl, der mit { anfaengt, damit reicht eigentlich die Pruefung auf ^{

es gibt glaube ich noch irgend wo ein timing problem oder eine race condition in verbindung mit codemiror:

Codemirror muss jemand anderes debuggen.

@Benni: Deine Probleme mit der Produktiv-Instanz kann ich nicht erklaeren: die Pruefung hat eigentlich nichts mit confgDb zu tun. Kannst du bitte pruefen, ob im telnet, mit modify das Problem auch existiert? Ich gehe davon aus, dass in deiner Produktiv-Umgebung perlSyntaxCheck aktiviert ist . Ich habe mit Chrome/FireFox/Safari kein Problem.

[justme1968]

die kurze antwort:
in einem ersten schritt einfach die seite mit location.reload(); neu laden wenn es keine meldung zum anzeigen gibt.

die lange antwort:
wenn du mit 'leere hülle' meinst die werte zeilen schon auf der seite zu haben aber ausgeblendet glaube ich nicht das das der richtige weg ist. zum einen gibt es zum teil sehr viele potentiell möglichen attribute, zum anderen wäre es auch für readings die nachträglich dazu kommen schön wenn sie einfach per longpoll auftauchen. wenn man das also einbaut dann gleich für readings und attribute.

d.h. für das entsprechende event nachschauen ob es die tabellen zeile wert schon gibt und wenn nicht in die tabelle einfügen/anhängen. das ist besser da es kein vorwissen braucht.

wenn das einfügen zu umständlich ist könnte man auch den wert dann ersetzen wenn er schon vorhanden ist und im anderen fall die seite neu laden.

oder wie oben vorgeschlagen mir location.reload(); die seite neu laden wenn ein attribut geändert wurde und es keine meldung/popup gab. das verhalten wäre dann genau so wie jetzt und es gäbe zusätzlich den syntax check.


zur geänderten regex: vielleicht wäre ^\s*{ noch besser? dann würde der check auch greifen wenn der command teil in die nächste zeile formatiert wurde.

[Benni]

@Benni: Deine Probleme mit der Produktiv-Instanz kann ich nicht erklaeren: die Pruefung hat eigentlich nichts mit confgDb zu tun. Kannst du bitte pruefen, ob im telnet, mit modify das Problem auch existiert? Ich gehe davon aus, dass in deiner Produktiv-Umgebung perlSyntaxCheck aktiviert ist . Ich habe mit Chrome/FireFox/Safari kein Problem.

- Ok! In telnet erhalte ich die Fehlermeldungen auch in meiner Produktiv-Instanz.
- die Fehlermeldungen kommen auch im FHEMWEB, wenn ich per defmod in der Kommandozeile per defmod ändere. Allerdings nicht in separatem Dialog.
- Wenn ich codemirror in meiner Produktivinstanz deaktiviere funktioniert auch die Ausgabe der Syntaxfehler in separatem Dialog.

Natürlich ist perlSyntaxCheck aktiviert

[rudolfkoenig]

wenn das einfügen zu umständlich ist könnte man auch den wert dann ersetzen wenn er schon vorhanden ist und im anderen fall die seite neu laden.

Gefaellt mir
- dein Patch ist drin
- Attribut-Events werden an das Frontend weitergeleitet, und online aktualisiert. Das ist auch ohne psc aktiv.
- Falls man ein neues Attribut setzen will, dann wird ein submit durchgefuehrt, wie bisher. Sonst, falls psc gesetzt ist, wird das Befehl mit XHR abgeschickt. Das hat etliche Nebeneffekte (wie z.Bsp. bei Hinzufuegen eines neuen Raumnamens als Zweit-Raum taucht dieser Raum nicht im Menue auf), ich hoffe aber, dass sie nicht tragisch sind.

zur geänderten regex: vielleicht wäre ^\s*{ noch besser?

Habs eingebaut.

[rudolfkoenig]

Seufz. Habs wieder auf  ^{.*}$ geaendert. Siehe https://forum.fhem.de/index.php?topic=52071

[justme1968]

das ist schade. aber vielleicht hilft die idee aus dem patch von hier: https://forum.fhem.de/index.php/topic,52242.msg440353.html#msg440353. ebenfalls.

der kann auch zusammengehörende klammer ebenen zusammen suchen.

da es nur im define/modify passiert sollte es zeitlich kein problem sein.