Hallo,
ich habe versucht es nochmal etwas besser aufzubereiten.
Angefügt ist ein nochmal vereinfachtes Mini-Modul, das die folgenden Regex-Attribute jeweils mit Hints 1,2,3 definiert.
$modHash->{AttrList} =
'attr1.*:1,2,3 ' .
'attr2.*:1,2,3 ' . # attr2b will be added to userattr with different hints
'attr3.*:1,2,3 ' . # attr3c will be added in .AttrList and userattr with different hints
'attr4.*:1,2,3 ' . # attr4d will be added in .AttrList
'attr5.*:1,2,3 ' .
$readingFnAttributes;
in der Define-Funktion werden zum Test ein paar davon mit anderen Hints konkretisiert:
$hash->{'.AttrList'} = $modules{$hash->{TYPE}}{AttrList} . ' attr3c:dotAc1,dotAc2,dotAc3 attr4d:dotAd1,dotAd2,dotAd3';
In der Konfiguration werden folgende Attribute gesetzt:
attr RTest attr1a 1
attr RTest attr2b 1
attr RTest attr3c 1
attr RTest attr4d 1
attr RTest userattr attr2b:ub1,ub2,ub3 attr3c:uc1,uc2,uc3
Wenn man jetzt im Browser auf attr1a klickt, erscheint das Attribut in der Attribut-Eingabe mit seinem Wert 1 aber ohne Auswahlliste. Früher ist beim Klick gar nichts passiert, daher ist das ein Fortschritt. Leider wird der Hint 1,2,3 nicht berücksichtigt. Deshalb müsste ein Modul immer noch zusätzlich beim Setzen der Ausprägung eines Regex-Attributs (hier attr1a:1,2,3 für das ursprüngliche Regex-Attribut attr1.*:1,2,3) z.B. einen userattr-Eintrag mit der Auswahlliste als Hint erzeugen.
Wenn man im Browser auf attr2b klickt, dann erscheint das Attribut mit dem Hint aus dem userattr (ub1,ub2,ub3). Das ist auch gut und der Benutzer könnte theoretisch sogar das userattr anpassen um andere Werte in die Auswahl zu setzen.
Wenn ein Modul wie HTTPMOD oder Modbus jetzt aber beim Setzen von attr2b automatisch ein userattr erzeugt (so wie bei HTTPMOD etc. bisher), dann beschweren sich die Benutzer, dass ihre Änderung am userattr verloren gehen (so bin ich auf das Thema aufmerksam geworden).
Also dachte ich dass es evt. ein eleganterer Weg wäre, aus dem Modul heraus statt userattr-Einträge zu erzeugen in $hash->{.AttrList} zu schreiben. Das verhält sich aber nochmal anders:
Wenn man im Browser auf attr3c klickt (dafür gibt es sowohl einen Eintrag in .AttrList als auch im userattr, dann hat die .AttrList offenbar Priorität und der Hint aus dem userattr wird nicht verwendet. Das ist also auch nicht die Lösung, da manche Anwender gerne die vorgegebenen Werte überschreiben würden.
Ich kann jetzt natürlich im Modul versuchen die Konflikte zwischen benutzerdefinierten Hints in userattr-Einträgen und solchen, die aus dem Modul kommen zu priorisieren. Im Zweifel wird der Hint vom Benutzer behalten. Aber so richtig schön ist das auch nicht.
Am besten würde es mir gefallen, wenn das Modul die userattr-Einträge nicht anfassen müsste und sie dem Namen entsprechend dem Benutzer lassen würde. Dann müsste aber Fhemweb die Hints auch aus Regex-Attributen berücksichtigen.
Gruss
Stefan