[patch] userReadings akzeptiert kein '.' im Namen

[Creideiki]

Hallo,

im Moment darf ein Reading, das mit userReadings angelegt wird, keinen Punkt im Namen haben, sonst wird das Reading silently ignored.
Das ist recht einfach zu beheben, indem in der entsprechenden RegEx der Punkt zugefügt wird (siehe Patch).

Was mit diesem Patch nicht behoben wird, ist, dass userReadings keine Fehlermeldung o.ä. ausgibt, wenn der Name nicht dem RegEx entspricht.

[rudolfkoenig]

Code Auswählen Erweitern

-      my $regexi= '\s*([\w-]+)(:\S*)?\s+((\w+)\s+)?({.*?})\s*';
+      my $regexi= '\s*([\w-\.]+)(:\S*)?\s+((\w+)\s+)?({.*?})\s*';

Ich weiss nicht genau was \w-\. macht, aber a- und a-z ist ein gewaltiger Unterschied.
Kannst Du das bitte pruefen?

[betateilchen]

Ich weiss nicht genau was \w-\. macht

Kannst Du auf http://regex101.com/ ausprobieren, da bekommst Du hervorragende Erklärungen bei der Analyse einer Regex:

Code Auswählen Erweitern


[\w-\.]+ match a single character present in the list below
Quantifier: Between one and unlimited times, as many times as possible, giving back as needed [greedy]
\w match any word character [a-zA-Z0-9_]
- the literal character -
\. matches the character . literally


[herrmannj]

Punkte in readings und im devicenamen produzieren in einigen frontends Fehler. Vorschlad ist eher das "silently" beseitigen. Dann bleibt Punkt verboten und user weiß es ...

vg
jörg

[Creideiki]

Sollte man dann nicht vielleicht die Frontends fixen...? 

[betateilchen]

Den Vorschlag, die Punkte komplett zu verbieten, unterstütze ich uneingeschränkt.

Beim devicename wäre das sogar sehr simpel umsetzbar, da dort bereits eine Prüfung auf "nur erlaubte" Zeichen stattfindet (die z.B. Leerzeichen bereits verbietet).

Bei den Namen von Readings wird das schwierig. Denn nicht alle Module bzw. deren Entwickler benutzen dir readings*Update Funktionen, die dafür eigentlich vorgesehen sind. Immer dort, wo die Readings im Modul direkt angelegt bzw. geändert werden, kann eine zentrale Prüfung nicht greifen. Nichtsdestotrotz würde ich auch bei den readings*Update Funktionen eine Prüfung auf erlaubte Zeichen befürworten.

[betateilchen]

Sollte man dann nicht vielleicht die Frontends fixen...? 

Das ist wie Kopfschmerztablette: Es bekämpft die Auswirkung, aber nicht die Ursache. Es gibt keinen sinnvollen Grund, Punkte in Namen von devices, readings und attributes zu verwenden.

[Creideiki]

Es gibt aus Anwendersicht aber auch keinen Grund, sie zu verbieten. Der einzige Grund, den ich sehe, ist, dass man bei RegEx etwas mehr aufpassen muss.

[hexenmeister]

Den Vorschlag, die Punkte komplett zu verbieten, unterstütze ich uneingeschränkt.

Beim devicename wäre das sogar sehr simpel umsetzbar, da dort bereits eine Prüfung auf "nur erlaubte" Zeichen stattfindet (die z.B. Leerzeichen bereits verbietet).

Dann muss man den Benutzer, die solche Namen verwendet haben, auch eine (am besten automatische) Migration zur Verfügung stellen.

[betateilchen]

Eine Meldung beim fhem-Start (sowohl im Frontend als auch im Logfile), dass in der bestehenden Konfiguration Namen existieren, die deprecated sind, würde im Rahmen einer angemessenen Übergangszeit dafür m.E. völlig ausreichen. Bei einem neuen fhem-Release kann man dann die Unterstützung abschalten.

[hexenmeister]

Eine Meldung beim fhem-Start (sowohl im Frontend als auch im Logfile), dass in der bestehenden Konfiguration Namen existieren, die deprecated sind, würde im Rahmen einer angemessenen Übergangszeit dafür m.E. völlig ausreichen. Bei einem neuen fhem-Release kann man dann die Unterstützung abschalten.

Du hättest ja brecht, wenn man von Benutzer ausginge, die sich mit Administration zumindest ein wenig beschäftigen (wollen/können). Diejenigen, die einmal pro Jahr Update machen, werden ganz schön laut aufschreien

[herrmannj]

Sollte man dann nicht vielleicht die Frontends fixen...? 

schon, aber: dummerweise verwenden browser Punkte in der dom-notation. Frameworks bauen darauf auf. Regex hat mit dem Punkt auf was eigenes vor. Wird ein mühsamer Weg denen allen das abzugewöhnen 

vg
jörg

[rudolfkoenig]

Punkt ist z.Zt. auch im Namen von Geraeten erlaubt, und beim Attribute/Reading/Hash-Eintrag wird es explizit ausgewertet: falls es mit Punkt beginnt, dann wird es erstmal nicht angezeigt, es sei denn man setzt showInternalValues.
Ich habe deswegen den Patch von Creideiki hinzugefuegt.

Wenn wir Punkt verbieten wollen, dann brauche ich erstens konkrete Probleme, und eine Ueberlegung, wo ueberall es verboten werden soll. Eine Warnung fuer Readings koennte man leicht in CommandSetReading einbauen, das wird beim Einlesen der Konfiguration aufgerufen.

[justme1968]

ich bin dagegen den punkt zu verbieten. es ist ein gutes trennzeichen und optisch sehr viel weniger aufdringlich als ein underscore.

neben dem punkt um die anzeige zu unterdrücken verwenden viele 1wire readings den punkt.

alte db und filelog einzräge warten auch erst mal nutzlos.

die ànderung wäre also auch tiefgreifender als nur eine warnung anzuzeigen. es wäre genau so ein schnellschuss mit zweifelhaftem nutzen wie er hier oft kritisiert wird.

ich denke es wäre besser zu dokumentieren welche zeichen wo erlaubt sind damit man es beim imentieren von schnittstellen oder frontends nicht vergisst.

gruß
  andre

[betateilchen]

Die vorgenommene Änderung funktioniert scheinbar nicht korrekt.

http://forum.fhem.de/index.php/topic,27566.0.html