diskussionsgrundlage: gruppieren von attributen

[justme1968]

es gab ja schon mehrfach die diskussion ob und wie man attribute gruppieren könnte. zuletzt bei der einführung von AttrRenameMap.

um hierbei weiter zu kommen habe ich mal eine mögliche variante implementiert:
- attribute können über einen <gruppe># prefix gruppiert werden
- modul spezifische attribute sollten einen <TYPE># prefix bekommen

- fhemweb zeigt die gruppen im attribut dropdown an
- die attribut tabelle in der detail ansicht ist um zwischenüberschriften für die gruppen erweitert

- das handling der attribut namen ist komplett in resolveAttrRename eingebaut

- removeFromAttrList hinzugefügt um die alten attributnamen ohne gruppe aus global zu entfernen
  -> beispiel fhemweb

um so weit wie möglich rückwärtskompatibel zu sein:
- resolveAttrRename schaut auch nach <TYPE>#<attrName> wenn es <attrName> nicht gibt
  - wenn eindeutig -> wird verwendet, wenn nicht -> fehler
  - es sind diverse shortcuts eingebaut. z.b. wenn ein attribut mit diesen namen bereits gesetzt ist
    wird der name direkt gültig erklärt

was man noch optimieren sollte:
- darstellung im menü mit css und/oder jquery verbessern -> echte submenüs
- darstellung in der detail ansicht mit css verbessern
- benchmark

was man noch einbauen sollte:
- ich denke alle attribute sollten case insensitiv sortiert werden
  -> FHEMWEB kommt nicht mehr am anfang
- darstellung der gruppen jeweils am ende nach allen nicht gruppieren attributen?
- idee um die gruppenüberschriften zu etwas leserlichem zu mappen
  d.h. aus dem lowerCamelCase prefix etwas sprechenderes machen.
  z.b. notifyAndroidTV -> Notify Andoid TV defaults
  -> z.b. über ein $hash->{AttrGroupNames} der in fhemweb über alle module gecached wird

---

eine alternative lösung bei der die gruppen nicht direkt über die attribut namen gebildet werden, sondern über ein $hash->{AttrGroups} in den modulen, habe ich mir auch schon angeschaut.
-> das geht nur wenn man identische attribut namen modul übergreifend verbietet
   da nach getAllAttr die zuordnung eines attributs zum modul verloren gegangen ist

[Wuehler]

Ohne die alten Diskussionen zu kennen: ich finde es gut.

[CoolTux]

Sieht wirklich gut aus. Ich werde das mal in mein Testsystem kippen.

[betateilchen]

den zweiten Screenshot verstehe ich nicht.

[justme1968]

die attribute die zu einer gruppe gehören (hier FHEMWEB und notifyAndroidTV) sind dort jeweils etwas eingerückt und mit einer zwischenüberschrift versehen. wenn man das nicht macht wird es unübersichtlich
da die attribut namen ja den <gruppe># prefix haben.

wie oben geschrieben muss die darstellung noch per css verbessert werden.

[betateilchen]

Naja, was mich im zweiten Screenshot irritiert: da steht zweimal das Attribut "icon" in der Liste.

[justme1968]

das icon attribut ist einmal in der fhemweb gruppe, und einmal in der notifyAndroidTV gruppe. der vollen namen sind FHEMWEB#icon und notifyAndroidTV#icon.

[Markus Bloch]

Generell finde ich den Ansatz echt cool. Für mich sind noch folgende Punkte unklar:

- soll das Attribut nachwievor am bisherigen Namen ("icon") eindeutig bleiben oder kann der gleiche Bezeichner in verschiedenen Gruppen benutzt werden? Was ist, wenn man AttrVal($name,"icon", ...) ausführt? Was hat dann Vorrang?
- $readingsFnAttributes sowie "do_not_notify" sollte dann in der InitialzeFn aus $hash->{AttrList} entfernt werden, damit dort wirklich nur noch modulbezogene Attribute enthalten sind. Das die readingFnAttributes verwendbar sollte man dann mit einem Flag in der InitializeFn in $hash anzeigen, damit diese in einer eigenen Gruppe (z.B. "Events") auftauchen.

[betateilchen]

das icon attribut ist einmal in der fhemweb gruppe, und einmal in der notifyAndroidTV gruppe.

Das habe ich schon verstanden. Aber wieso können bei einem device die gleichnamigen Attribute aus verschiedenen Gruppen auftauchen?

[justme1968]

@Markus Bloch: da unter der haube die attribut namen aus <gruppe>#<name> gebildet werden erlaubt der vorschlag oben den gleichen namen in mehreren gruppen zu verwenden.

der zugriff über AttrVal, attr, deleteattr, ... kann entweder über den vollen namen <gruppe>#<name> erfolgen. dann ist alles eindeutig. module die ihre attribute in eine gruppe stecken sollten die eigenen attribute über vollen namen prüfen.

aus rückwärts kompatibilitätsgründen (und weil es sich einfacher tippen läßt) kann man aber auch weiter über nur <name> zugreifen.
dabei gibt es folgenden vorrang:
1. wenn es das attribute ohne gruppe gibt hat es vorrang
2. wenn das attribut genau ein mal in einer gruppe auftritt kann man <name> als abkürzung
   für <gruppe>#<name> verwenden. d.h. wenn man z.b. alle FHEMWEB attribute in eine gruppe
   steckt kann man trotzdem noch wie bisher AttrVal($name,"icon", ...)  verwenden und muss nicht
   alten code anfassen. damit ist auch der neustart nach dem update behandelt wenn ein modul seine
   attribute auf gruppierte ändert. die attribut namen werden automatisch migriert.
   ohne gruppe werden automatisch auf neue mit gruppe umgesetzt.
3. wenn der gleiche namen in der attribut liste eines device durch mehrere gruppen vorkommt greift
   der # shortcut von 2. nicht mehr und es gibt eine meldung.

zu $readingFnAttributes: wenn man das so macht muss man jedes modul anfassen. das ist garnicht nötig. es reicht in fhem.pl die initialisierung von $readingFnAttributes so zu ändern das jeder name mit einem Events# prefix versehen wird. alles andere geht automatisch.

aber weiter gedacht: gibt es überhaupt einen grund warum $readingFnAttributes nicht einfach immer für jedes modul zur verfügung steht? dann könnte man $readingFnAttributes auch durch "" ersetzen und die namen (mit de, Events# prefix) über getAllAttr immer hinzufügen.

bei do_not_notify ist es leider nicht so einfach. da müsste tatsächlich jedes modul angefasst werden.
zu $readingsFnAttributes: es reicht wenn


@betateilchen: weil ein device ja nicht nur attribute für den eigenen device typ haben kann sondern nach wie vor auch global für alle devices attribute hinzufügen kann. fhemweb fügt für alle devices das icon attribut hinzu. notifyAndroidTV hat für jeden möglichen parameter der in der notification gesendet wird die möglichkeit einen default im gleich lautenden attribut zu hinterlegen.

[betateilchen]

Also für mich ist die Anzeige nun zwar gruppiert, aber noch unübersichtlicher als vorher. Das mit den mehrfach auftauchenden Attributen finde ich extrem unlogisch und verwirrend.

[betateilchen]

@betateilchen: weil ein device ja nicht nur attribute für den eigenen device typ haben kann sondern nach wie vor auch global für alle devices attribute hinzufügen kann. fhemweb fügt für alle devices das icon attribut hinzu. notifyAndroidTV hat für jeden möglichen parameter der in der notification gesendet wird die möglichkeit einen default im gleich lautenden attribut zu hinterlegen.

Man möchte doch nicht in jedem device alle in FHEM möglicherweise vorkommenden Attribute sehen, sondern nur die, die auch beim aktuellen device möglich sind.

Grundsätzlich finde ich die Idee der Gruppierung gut. Vielleicht verstehe ich auch einfach das gesamte Konzept noch nicht. 

[justme1968]

die gleich lautenden attribute sind ein sonderfall und nicht die regel. aber so immer noch besser als sich z.b. namen aus den finger zu saugen die zwar das gleiche bedeuten sollen, sich irgendwie unterscheiden müßen.

im übrigen wird das notifyAndroidTV icon attribut vermutlich am ende vermutlich defaultIcon heissen und damit wieder eindeutig sein.


was die darstellung angeht: wie oben geschrieben muss man da noch mit css und/oder besseren widgets nachhelfen. aber ohne die infrastruktur unten drunter kann man nicht an der darstellung arbeiten und alternativen vergleichen.


es sind doch auch nicht alle möglichen attribute zu sehen sondern nur die, die für dieses device tatsächlich möglich sind. FHEMWEB attribute sind nur mal für alle devices möglich. die Event attribute im prinzip auch.  du siehst aber z.b. oben keine hm spezifischen attribute weil der screenshot nicht von einem hm device ist.

[zap]

Wie wäre es denn, wenn man im ersten Schritt oder auch als Default einstellung feste Gruppen vorsieht, z.B.

- Web
— widgetOverride
— cmdIcon
— icon
— ...
- Events
— event-on-update-reading
— ...
- Modulname
— ModAttr1
— ModAttr2
— ...

[Phill]

Hallo,
Find ich super das du hier mal einen  Anfang machst, absolut notwendige Maßnahme.

Ich wollte mir das mal anschauen und habe festgestellt, das mit der aktuellen Revision der patch fehl schlägt.
Ich habe dann mal mit der gleichen Revision geladen, und es scheint zu funktionieren, nur wird das DropDown bei mir nicht gegliedert.
Und zwar scheitert es an folgender Zeile in der sub FW_select($$$$$@)

Code Auswählen Erweitern

    if($element && $name eq 'arg.attrnb') {
Bei mir steht in $name etwas in dem Stil: "arg.attr<devicename der in FHEMWEB geöffnet ist>"
arg.attrnb erschließt sich mir nicht.
Mit

Code Auswählen Erweitern

    if($element) { funktioniert es jedenfalls.

Gruß