Die liste der Attribute ist gruppiert und sub-sortiert. Sehr gut.
Die Gruppen sind ebenfalls sortiert. Gut. Leider alphabetisch.
M.E. sollten die spezifischen Attribute oben stehen. Die globalen unten. Natürlich sind andere Sortierungen auch möglich.
Modul, global, others
Global, modul,others
Unpassend ist, dass die spezifischen (modul) am Ende stehen.
Insbesondere wenn entity-specific statt modul genutzt werden
Um es genauer zu beschreiben:
- die Sortierung nach Gruppen findet in FHEMWEB statt
- alle Module, die Attribute beitragen, werden unter dem Modulnamen als Gruppe gefuehrt.
- die sogenannten "global" Attribute werden unter "framework", die userattr unter "global userattr" oder "device userattr" gefuehrt.
- die Gruppen werden alphabetisch sortiert
Ich gehe davon aus, dass die gewuenschte Reihenfolge der Gruppen subjektiv ist, und manchmal vom Mondstand abhaengig ist.
Ich kann nachvollziehen, dass ein Maintainer die eigenen Attribute vorne sehen will, und ich bin bereit diese Gruppe nach vorne zu schieben, falls das auch "normale" Benutzer so sehen.
Erfahrungsgemäß tun sich Nutzer (also Menschen, die "nur" ihr Smarthome steuern möchten, ohne Informatik-Aufbaukurs) eher schwer mit Attributen. Ich hatte v.a. bei früheren Versionen von HMCCU exzessiv Attribute eingesetzt, um Device Definitionen so flexibel wie möglich zu machen. In der aktuellen Version soll man nun komplett ohne modulspezifische Attribute nutzen können.
Die besten Attribute sind die, die man nicht benötigt ;)
Zur eigentlichen Frage kann ich zwar verstehen, dass Bedenken bzgl. des Mondstandes da sind, würde mich aber auch freuen, wenn zuerst die moduleigenen Attribute kämen, also +1 zu diesem Vorschlag.
Weitere Gedanken (bestimmt noch nicht vollständig):
- dann vielleicht die readingFnAttributes (framework),
- ob man nicht FHEMWEB und framework zusammenfassen sollte? (= nach vorne, was häufiger gebraucht wird).
- die case-sensitive Sortierung ist vermutlich auch nicht für alle User nachvollziehbar (dann käme uU. auch "device userattr" weiter nach vorne)...
Bei hmccu waren in der tat extrem viele Attribute möglich. Sehr unschön war, dass es für einen normalen und sinnvollen betrieb schon notwendig war, etliche, zum teil kryptische zu setzen.bei hmccu konnte ich es mir nicht merken. Einige habe ich nie verstanden. Andere wäre durch globale abzudecken gewesen.
Somit reduziert sich die Anzahl der modulspezifischen gewaltig.
Allerdings bitte nicht Äpfel mit Birnen vergleichen. Hmccu bildet HW ab, welche schlicht "gegeben" ist. Virtuelle entities definiere sich aus attributen, oder sollten das zumindest.
Virtuelle entities in cul_hm werden komplett über attribute definiert. Damit werden fhem-übliche mechanismen genutzt zur Sicherung und recovery. Weiter ist es user-sichtbar und ggf beeinflussbar.
Mir ist eine definierte und einheitliche reihenfolge wichtig über alle Module. Sinnlose attribute sollten nicht erscheinen. Daher war es übrigens sehr zu begrüßen dass nun auch entity-spezifische attributlisten möglich sind
ZitatMir ist eine definierte und einheitliche reihenfolge wichtig über alle Module.
Na definiert und einheitlich ist ja die Reihenfolge.
Ich bin nur noch nicht ueberzeugt, dass ich sie aendern soll. :)
Definiert ist sie.... so lala.
Alphabetisch ist eine sortierung. Die ist aber nicht gewichtet.
Global kommt immer. Web eigentlich auch. Das Modul mal vorher mal nachher. Oder zwischendrin.
Modulattribute sind spezifisch für dieses Element und haben damit den ersten Platz verdient. Glasklar. Dass sie sinnvoll sind hoffe ich doch.
Danach ist mir egal. Global wäre bei mir next. Der Rest alphabetisch ist ok.
Aber wir sind selten einer Meinung. Also besser nix ändern.
Hier muss ich Martin recht geben. Dass die modulspezifischen Attribute nicht konsistent am gleichen Platz stehen, hat mich schon oft irritiert.
ok, noch ein Nachsatz:
Ich hasse "suchen" und liebe "finden" oder "merken".
Global User kommt immer vor und sollte an immer der gleichen stelle erscheinen. framework dito. fhemweb dito.
Nachdem sich die Namen nicht ändern ist ein "sort" ok.
Dynamisch ist dann in erster Linie "module". hier wird der Module-name genutzt - und damit begint das kuddelmuddel.
Es gibt viele Wege, dies zu beheben.
=> statisch ist pflicht
=> gewichtung-sort geht vor string-sort
so, für mich erledigt
Mich stört, dass die modulspezifischen Attribute nicht am Anfang stehen. Vom speziellen ins allgemeine. Die modulspezifischen gehören für mich an den Anfang.
Ich habe die modulspezifischen Attribute nach vorne gezogen.