Diskussion: Verzeichnisstruktur von fhem - jetzt und in Zukunft

[Prof. Dr. Peter Henning]

Ich denke, es ist Zeit, sich über eine andere Verzeichnisstruktur Gedanken zu machen. Vielleicht hat das ja jemand schon getan - dann bitte ich um Korrektur.

Grund: Im Hauptverzeichnis stehen inzwischen ca. 300 Dateien. Teilweise mit Nummerierung vorne dran, teilweise ohne. Teilweise Frontendmodule, teilweise Backendmodule, teilweise Systemerweiterungen - wie auch immer man es dreht und wendet, die Übersicht geht so langsam in den Keller.

Anregung:

1.Gliederung entsprechend der Commandref, also in commands, devices, helpers mit jeweils eigenem Unterverzeichnis FHEM/commands, FHEM/devices, FHEM/helpers
2.Festlegung, wo sub-Module etc. abgelegt werden. So könnte man z.B. neben dem Modul FHEM/devices/00_OWX.pm noch das Verzeichnis FHEM/devices/OWX haben und darin alle Hilfskonstrukte ablegen, die eventuell importiert werden müssen. Beim Update wäre dann relativ leicht festzulegen, dass ein Update des Unterverzeichnisses  nicht separat erfolgt, sondern genau dann, wenn das Haupt-Devicefile sich geändert hat.

LG

pah

[tupol]

Stimme ich voll zu. Dann muss aber auch der Wiki-Eintrag verbessert bzw. erzeugt werden, denn ohne Anleitung kommt es wieder zum Chaos. (z.B verstehe ich unter einem Helper-Modul, ein Modul dass etwas zu anderen Modulen hinzufügt oder von Ihnen ausliest und das ist z.B. FB_CALLMONITOR nicht.)

Dasselbe inflationäre Chaos herrscht auch in gplot. Da packt jeder seine Modul-gplots rein, egal ob die jemand braucht oder nicht.

[betateilchen]

Dasselbe inflationäre Chaos herrscht auch in gplot. Da packt jeder seine Modul-gplots rein, egal ob die jemand braucht oder nicht.

DAS nervt mich am allermeisten! Man kann den überschüssigen "Müll" in dem Verzeichnis gar nicht so schnell löschen, wie er da per update reingespült wird. Gerade habe ich dort wieder eine Datei "sysstat.gplot" löschen müssen, die ich dort nicht haben möchte.

Meines Erachtens gehören gplot Dateien grundsätzlich nach contrib, von wo man sich die Dateien, die man wirklich braucht, in das aktiv genutzte gplot Verzeichnis kopieren kann. (Ausser der template Datei brauche ich z.B. überhaupt keine der standardmäßig ausgelieferten gplot Dateien)

[Prof. Dr. Peter Henning]

Tja, das könnte man natürlich auf alle anderen Verzeichnisse ausweiten.

Oder, wenn wir schon beim Wiki sind: Warum nicht das Wiki zu einem SMW (Semantic Media Wiki) erweitern, so dass man eine etwas clevere Suche nach beispielhaften gplot files an Hand der gewünschten Attribute durchführen kann ? Ich gebe ja zu, dass so etwas mein Arbeitsgebiet ist - aber warum sollte man das nicht einmal praktisch umsetzen ?

LG

pah

[betateilchen]

Oder, wenn wir schon beim Wiki sind: Warum nicht das Wiki zu einem SMW (Semantic Media Wiki) erweitern

Weil das WIKI - gelinde gesagt - in seiner derzeitigen Form eine Katastrophe ist, zumindest inhaltlich, und wenn es darum geht, dort wirklich eine Information zu finden, von der man weiss, dass sie dort irgendwo vergraben ist.

[betateilchen]

Ich denke, es ist Zeit, sich über eine andere Verzeichnisstruktur Gedanken zu machen.

*unterschreib*

[Markus Bloch]

*unterschreib*

[justme1968]

welches problem soll eine andere directory struktur lösen?

das fhem selber ein file nicht findet kann es ja nicht sein. so wie man auf dem standpunkt stehen kann das es dem anwender egal sein soll wie das konfig file strukturiert ist kann man auch der meinung sein so lange fhem die files findest ist es wursch wie viele davon in einem verzeichnis liegen. also muss es etwas anderes sein...

• das es zu viele fhem module gibt?
    -> das ist doch kein nachteil
• das in FHEM nicht nur die module sondern noch ein paar hilfs files liegen?
    -> es sind unter 10%. ob das stört ist sicher ansichtssache.
• etwas nach contrib zu tun ist so lange nicht gut wie es vom update ausgeschlossen ist.
• eine bessere organisation?
  
  
  
  • wie oben vorgeschlagen an der commandref orientiert?
      -> ich glaube das hilft nicht wirklich weiter. zum einen ist die einteilung nicht eindeutig
      -> zum anderen bleibt wieder ein recht grosser anteil (die devices) beisammen.
  • das aufsplittern nach einem anderen kriterium?
      -> ist wirklich aufteilen der richtige ansatz? oder doch eher zusammen suchen was zusammen gehört?
  • das zusammenhalten aller files die zu einem modul gehören (z.b. modul file, hilfs files, plot vorlagen, doku)
      -> es gibt wenig module mit mehr als einem file

ps: ich finde es ziemlich daneben etwas als müll zu bezeichnen nur weil man selber keine verwendung dafür hat (wie ich z.b. bbb module).

pps: die plotfiles sind seit es den plot editor gibt nicht mehr so wichtig wie sie mal waren. ich glaube aber es hilft immer noch vielen mal nachsehen zu können.

[betateilchen]

ps: ich finde es ziemlich daneben etwas als müll zu bezeichnen nur weil man selber keine verwendung dafür hat (wie ich z.b. bbb module).

da waren Anführungszeichen drumrum

pps: die plotfiles sind seit es den plot editor gibt nicht mehr so wichtig wie sie mal waren.

Genau das ist doch der Punkt. Nur zum Nachschauen brauche ich die nicht unter Edit Files.

[rudolfkoenig]

Die Argumente von Andre vertrete ich auch, hier sind noch weitere:
- fhemupdate.pl (das Ding, was einmal am Tag die Dateien aus SVN nach fhem.de schiebt), ist z.Zt. nicht in der Lage Verzeichnisse automatisch zu kopieren, ich muss neue Verzeichnisse eintragen. Falls es sich rausstellt, dass mehrere Module Hilfsdateien brauchen, dann werde ich das aber automatisieren (muessen).
- 98_update.pm ist nicht wirklich in der Lage, Dateien zu verschieben. Es gibt zwar MOVE Befehle in control_fhem.txt, aber sie werden auch Jahre nach der Umorganization bei jedem update immer wieder durchgefuehrt, weil man nicht so recht weiss, ob es noetig ist oder nicht.
- Verzeichnisumorganisation bringt immer Verwirrung bei den Benutzer nach sich, wenn man es macht, dann sollte man gute Gruende dafuer haben, und fehlerfrei durchfuehren. Die Trennung von Bildern,Modulen und .gplot Files hat vielen einiges an Support-Stunden gekostet, und diese Trennung war sehr klar.

Fuer die .gplot/.css Dateien habe ich noch keine gute Loesung, das Problem sehe ich aber auch.

[betateilchen]

klingt ein bisschen nach "das machen wir schon immer so" ...

Die Tatsachen, dass fhemupdate.pl und 98_update.pm bestimmte Dinge einfach derzeit nicht können, ist doch kein Argument dafür, etwas deswegen nicht ändern zu können, denn solche Skripte sind nicht in Stein gemeißelt, sondern lassen sich wie alle anderen Dinge in und um fhem ändern. Vorausgesetzt, man möchte etwas ändern.

[svenson08]

Und wenn man mit einem neuen Release eine neue Verzeichnisstruktur einführt und mit dem Release Wechsel ein migrationsscript ausliefert?
Andere bekommen das auch hin. Alte Zöpfe sollte man auch mal abschneiden. Mir erscheint es manchmal als ob das zögerliche Vorgehen (was durchaus berechtigt sein mag) einer Weiterentwicklung (Verbesserung) im Wege steht. An der Freiwilligen Power in diesem Projekt wird das meiner Beobachtung nach nicht scheitern.

Vielleicht sollte man
1.) festlegen ob dieses Thema eines ist das umgesetzt wird
Und dann
A) ein extra thread zu dem Thema öffnen
B) todo's sammeln
C) diese todo's auf verschiedenen Personen verteilen.

Erstmal ist dieser Diskussionspunkt wie so viele. Es wird nichtfestgehalten ob dies gemacht wird oder nicht.

[tupol]

Vorschlag für das gplot Verzeichnis:

Im Verzeichnis www/gplot  nur ein Standard-Template und die gplots für die autocreate-Funktionalität zulassen.

Den Rest in ein Unterverzeichnis www/gplot/templates/unknownModul

Dann kann jeder für seine gplots ein Modulunterverzeichnis anlegen (z.B. www/gplot/templates/LUXTRONIK2) und dort seine gplots hin verschieben. Dann wäre zumindest die inflationäre Summe gelöst und man kann auch zwischen filelog und dblog unterscheiden.

Gruß

tupol

[betateilchen]

Das mit den modulspezifischen Unterverzeichnissen funktioniert nicht so einfach, weil neuangelegte Unterverzeichnisse nicht automatisch per update ausgeliefert werden.

Aber EINEN Unterordner für alle gplot Dateien ./www/gplot/templates würde ich auch begrüßen. Dann würden sich im ./www/gplot nur noch die tatsächlich benötigten gplot-Dateien befinden. Die gleiche Vorgehensweise würde ich auch bei den styles begrüßen.

Ob man gplot per autocreate wirklich überhaupt noch braucht, könnte man separat diskutieren. Mit dem plot-Editor lassen sich nach meiner Erfahrung die plot-Dateien schneller selbst anlegen als das Ändern vorhandener Vorlagen dauert. Denn das, was ein Modulautor in einer gplot Datei ausliefert, ist doch 100% willkürlich nach seinem eigenen Gusto festgelegt und keineswegs für alle Anwendungsfälle - selbst des gleichen Moduls - geeignet.

Wenn es nach mir ginge: Überhaupt keine gplot Dateien mehr ausliefern, ausser der template-Datei, die beim Klick auf den Link "Create SVG from Log" benötigt wird.

[tupol]

Ich kann mich noch an meine Anfangszeit erinnern. Ich fand autocreate-Plots sehr, sehr hilfreich.