FHEM Housekeeping
Martin Fischer
in letzter Zeit tummeln sich im {modpath}/FHEM immer mehr Dateien, besonders
wenn pgm2 zum Einsatz kommt. Im Zuge der Weiterentwicklung der OWFS-Module
wollte ich ein bereits bestehendes Perl-Modul (konkret OWNet.pm) nicht
komplett neuschreiben und in das OWFS-Modul sondern mittels require einbinden.
Aber dieses Modul wollte ich nicht auch noch unter {modpath}/FHEM ablegen.
Dazu habe ich die Tage mit Rudi gesprochen, was er denn davon halte in
{modpath}/FHEM auch Unterverzeichnisse anzulegen. Meine erste Idee war in
{modpath}/FHEM ein Verzeichnis namens lib anzulegen und dies als "Heimat" für
ergänzende Module zu nutzen.
Von Rudis Seite her spricht nichts dagegen, denn auch ihm wird {modpath}/FHEM
inzwischen zu voll. Allerdings würde das dazu führen, das evtl. bestehende
Funktionalitäten erstmal nicht damit klarkommen und angepasst werden müssten.
Beispiele dafür sind contrib/fhemupdate.pl, make, Fritz!Box Images, sowie pgm2
und ggf. weitere Module.
Rudi hat derzeit nicht die Möglichkeit dort grosse Teile zu übernehmen, so
dass ich mich der Sache angenommen habe.
Dazu habe ich gestern in einem ersten Schritt das Makefile überarbeitet. Neben
einer etwas moderateten Ausgabe habe ich noch weitere targets wie uninstall,
backup und andere Änderungen vorgenommen. Mittels install-pgm2 wird nun unter
{modpath} ein neues Verzeichnis htdocs angelegt, welches dann auch alle Files
von pgm2 (ausser die *.pm, die natürlich im {modpath}/FHEM abgelegt werden)
beinhaltet. Die relevanten Module wurden angepasst und soweit funktioniert das
auch alles. Es fehlt noch die Anpassung von contrib/fhemupdate.pl sowie der
Fritz!Box Images.
Nachdem ich heute weiter ans Werk gehen wollte, kam mir ein weiterer Gedanke,
den ich hier nur _kurz_ andiskutieren möchte um dann _schnell_ zur Tat zu
schreiten.
Aktuell sieht {modpath} ja wie folgt aus:
/usr/share/fhem
/usr/share/fhem/contrib
/usr/share/fhem/FHEM
Um FHEM nun etwas mehr zu strukturieren (in Hinblick auf die künftige
Entwicklung) habe ich mir folgendes überlegt:
/usr/share/fhem
/usr/share/fhem/contrib
/usr/share/fhem/lib (Optional modules)
/usr/share/fhem/lib/site (Optional modules/site)
/usr/share/fhem/locale
/usr/share/fhem/locale/de_DE
/usr/share/fhem/locale/en_EN
/usr/share/fhem/www
/usr/share/fhem/www/doc
/usr/share/fhem/www/pgm2
Dazu eine kurze Erläuterung:
/usr/share/fhem/contrib
Inhalt wird beibehalten.
/usr/share/fhem/lib
Enthält _alle_ zur Laufzeit benötigten core-Module (00_nnn.pm,...,99_nnn.pm).
Statt lib wäre auch die Bezeichnung modules (bzw. modules/site) denkbar.
/usr/share/fhem/lib/site
Enthält erweiterte Module, die von core-Modulen mittels use (Erweiterung von
@INC notwendig) oder require eingebunden werden sollen. Z.B. OWNet.pm.
/usr/share/fhem/locale
Enthält weitere Unterverzeichnisse (z.B. de_DE, en_EN) für eine evtl. künftige
Lokalisierung von FHEM / Modulen.
/usr/share/fhem/www
Enthält die zur Laufzeit installierten Web-GUIs (z.B. pgm2), sowie allgemein
bereitgestellte Files (in doc z.B. commandref.html, faq.html, fhem.html, etc.)
Die Struktur wäre dann für alle bestehenden und küntigen Module bindend. Die
Anpassungen würde ich weitestgehends alleine durchführen. Ggf. bräuchte ich
Unterstützung bei dem Fritz!Box Images (meine 5 "Fritten" sollen
"jungfräulich" bleiben) sowie bei contrib/fhemupdate.pl (da es ein
serverseitiges Script auf Rudis Webserver ist).
Ich würde mich freuen, wenn wir uns dazu _kurz_ Abstimmen könnten und ich ein
paar Meinungen lese.
Gruß Martin
Jan-Hinrich Fessel
Am 09.03.2012 um 21:36 schrieb Martin Fischer:
> Von Rudis Seite her spricht nichts dagegen, denn auch ihm wird {modpath}/FHEM
> inzwischen zu voll.
> Allerdings würde das dazu führen, das evtl. bestehende
> Funktionalitäten erstmal nicht damit klarkommen und angepasst werden müssten.
> Beispiele dafür sind contrib/fhemupdate.pl, make, Fritz!Box Images, sowie pgm2
> und ggf. weitere Module.
>
> Rudi hat derzeit nicht die Möglichkeit dort grosse Teile zu übernehmen, so
> dass ich mich der Sache angenommen habe.
>
> Dazu habe ich gestern in einem ersten Schritt das Makefile überarbeitet. Neben
> einer etwas moderateten Ausgabe habe ich noch weitere targets wie uninstall,
> backup und andere Änderungen vorgenommen.
Ich hab lokal auch ein "update" im Makefile, damit ich direkt aus dem lokalen svn updaten kann.
Und auch am Anfang etwas rumgemacht:
# set PREFIX (default "/usr")
PREFIX=/usr/local
# prefix for config files (default "")
ETCPREFIX=/usr/local
BINDIR=$(PREFIX)/bin
MODDIR=$(PREFIX)/share/fhem
DOCDIR=$(PREFIX)/share/doc/fhem
MANDIR=$(PREFIX)/share/man/man1
ETCDIR=$(ETCPREFIX)/etc
VARDIR=/var/log/fhem
> Um FHEM nun etwas mehr zu strukturieren (in Hinblick auf die künftige
> Entwicklung) habe ich mir folgendes überlegt:
>
> /usr/share/fhem
> /usr/share/fhem/contrib
da sehe ich jetzt nicht den funktionalen Unterschied zur nächsten Zeile
> /usr/share/fhem/lib (Optional modules)
> /usr/share/fhem/lib/site (Optional modules/site)
> /usr/share/fhem/locale
> /usr/share/fhem/locale/de_DE
> /usr/share/fhem/locale/en_EN
> /usr/share/fhem/www
> /usr/share/fhem/www/doc
> /usr/share/fhem/www/pgm2
/usr/share/fhem/pics
Für die ganzen vielen icons.
Und, ganz wichtig, alles schön konfigurierbar. Also mindestens $(prefix)/share/fhem.
Idealerweise aber pro Funktion, also etwa
prefix=/usr/local
fhembasedir=fhem
libdir=$(prefix)/$(fhembasedir)/lib
sitelib=$(libdir)/site
localedir=$(prefix)/$(fhembasedir)/locale
wwwdir=/usr/local/httpd/fhem
docdir=$(wwwdir)/wwwdocs
[...]
>
> Die Struktur wäre dann für alle bestehenden und küntigen Module bindend.
Unschön. Sollte in die config bzw. in eine separate Konfig geschrieben werden, generiert aus dem Makefile.
Wobei ich nicht sehe, was die Dateibaumstruktur für größere Auswirkungen haben könnte. Sowie man Pfade anfängt hart zu kodieren, begibt man sich in die Gefahr, das nicht mehr einfach wartbar zu haben. Und zum Module nachladen reicht ja der perl-Pfad.
> Die
> Anpassungen würde ich weitestgehends alleine durchführen. Ggf. bräuchte ich
> Unterstützung bei dem Fritz!Box Images (meine 5 "Fritten" sollen
> "jungfräulich" bleiben)
Hab nur eine, die fasse ich nicht an. Die soll Internet bereitstellen, sonst nix.
> sowie bei contrib/fhemupdate.pl (da es ein
> serverseitiges Script auf Rudis Webserver ist).
>
> Ich würde mich freuen, wenn wir uns dazu _kurz_ Abstimmen könnten und ich ein
> paar Meinungen lese.
Gerne ;-)
Schöne Grüße
Oskar
Rudolf Koenig
- /usr/share/fhem/FHEM wird nach /usr/share/fhem/lib umbenannt
- die docs wohnen nicht nur in doc sondern zusaetzlich in www/doc. Das finde
ich merkwuerdig: diese wurden nur deswegen nach FHEM kopiert, damit FHEMWEB
nur dieses Verzeichnis bedienen muss, damit es moeglichst einfach bleibt.
Wenn das letzte Argument wg. Strukturierung aufgeweicht wird, dann koennten
die Daten auch direkt aus dem "richtigen" doc gelesen werden.
Oder wir schieben doc auch im SVN hierher.
- die Begruendung von lib/site verstehe ich nicht. Ich wuerde verstehen, wenn es
nicht Teil der fhem Distribution ist, sondern nur lokale Aenderungen
beinhaltet.
- Es wird irgendwo auch noch modulspezifische Unterverzeichnisse geben muessen,
siehe die aktuelle HM Diskussionen.
- FHEMWEB muss nicht mehr aus FHEM sondern aus lib, lib/site(?), www/doc und
www/pgm2 Daten zurueckliefern. D.h. die neuen Verzeichnisse muessen irgendwo
im Programm spezifiziert werden (attr global ...). Entweder einzeln, oder als
Root-Pfad. Bitte beachten, dass ich bei fhem bei der Entscheidung "einfach
oder extrem Konfigurierbar" bisher immer die Loesung "einfach" gewaehlt habe.
- Diese Liste gilt dann auf fuer fhemupdate bzw. updatefhem.
- Doku muss auch angepasst werden, und eine Anleitung fuer migrieren.
Martin Fischer
Am Samstag, 10. März 2012, 01:29:21 schrieb Jan-Hinrich Fessel:
> [...]
>
> Ich hab lokal auch ein "update" im Makefile, damit ich direkt aus dem
> lokalen svn updaten kann.
auch gut ;-) Schau ich mir mal an.
> Und auch am Anfang etwas rumgemacht:
> # set PREFIX (default "/usr")
> PREFIX=/usr/local
> # prefix for config files (default "")
> ETCPREFIX=/usr/local
> [...]
ebenfalls machbar..
Muss ich jedoch prüfen ob das was mit make deb oder mit den Fritzboxen bricht.
> [...]
> > /usr/share/fhem/contrib
>
> da sehe ich jetzt nicht den funktionalen Unterschied zur nächsten Zeile
>
> > /usr/share/fhem/lib (Optional modules)
Der Unterschied ist, das alle Module in lib und lib/sites beim Start vorhanden
sind und in contrib nach wie vor die optionalen Module, die der Nutzer sich
dann bei Bedarf in lib reinkopieren kann. Das unterscheidet sich nicht von dem
jetzigen Stand.
> [...]
> > /usr/share/fhem/www/pgm2
>
> /usr/share/fhem/pics
> Für die ganzen vielen icons.
Das würde ich nicht machen wollen! icons gehören zu der jeweiligen GUI und im
Beispiel von pgm2 dann nach www/pgm2.
> Und, ganz wichtig, alles schön konfigurierbar. Also mindestens
> $(prefix)/share/fhem. Idealerweise aber pro Funktion, also etwa
> prefix=/usr/local
> fhembasedir=fhem
> libdir=$(prefix)/$(fhembasedir)/lib
> sitelib=$(libdir)/site
> localedir=$(prefix)/$(fhembasedir)/locale
> wwwdir=/usr/local/httpd/fhem
> docdir=$(wwwdir)/wwwdocs
> [...]
Ja, im Prinzip bin ich da bei Dir. Das sollten wir aber nochmal vertiefen. Wie
Rudi auch verfolge ich eigentlich KISS (Keep it Small and Simple). Wenn wir
nun alles über das System verteilen, dann erschwert das die Wartbarkeit.
Besonders in Hinblick auf fhemupdate.pl
> > Die Struktur wäre dann für alle bestehenden und küntigen Module bindend.
>
> Unschön. Sollte in die config bzw. in eine separate Konfig geschrieben
> werden, generiert aus dem Makefile. Wobei ich nicht sehe, was die
> Dateibaumstruktur für größere Auswirkungen haben könnte.
> [...]
Auch hier bin ich im Prinzip bei Dir. Aber auch hier der obige (KISS) Hinweis.
> [...]
> > Unterstützung bei dem Fritz!Box Images (meine 5 "Fritten" sollen
> > "jungfräulich" bleiben)
>
> Hab nur eine, die fasse ich nicht an. Die soll Internet bereitstellen,
> sonst nix.
Jepp! Dito..
> [...]
> > Ich würde mich freuen, wenn wir uns dazu _kurz_ Abstimmen könnten und ich
> > ein paar Meinungen lese.
>
> Gerne ;-)
Danke für die Anregungen!
Martin
Martin Fischer
> Verstehe ich die Unterschiede richtig:
JAIN :-)
> - /usr/share/fhem/FHEM wird nach /usr/share/fhem/lib umbenannt
Ja. Oder in modules. Was halt passender ist.
> - die docs wohnen nicht nur in doc sondern zusaetzlich in www/doc. Das finde
> ich merkwuerdig: diese wurden nur deswegen nach FHEM kopiert, damit FHEMWEB
> nur dieses Verzeichnis bedienen muss, damit es moeglichst einfach bleibt.
> [...]
Nein, die docs "wohnen" weiterhin in doc unter /usr/share/doc/fhem. nur die
mandatory docs wie commandref.html, faq.html und HOWTO.html, etc. die in den
GUIs aufgerufen werden können sollten in www/doc. Der Gedanke dabei ist: Wenn
mehrere GUIs installiert sind und jeder jeweils diese Dateien anzeigen will,
dann müssen sie nur an einer zentralen Stelle liegen.
Andere Dokumente wie *.txt, README, etc. sowie die Unterverzeichnisse bleiben
dort wo sie bisher auch sind.
> - die Begruendung von lib/site verstehe ich nicht. Ich wuerde verstehen,
> wenn es nicht Teil der fhem Distribution ist, sondern nur lokale
> Aenderungen beinhaltet.
Nicht ganz. Folgender Gedanke als Beispiel:
00_OW.pm benötigt eine Verbindung zum OWFS-Server. Dieses kann man nun 1:1
nachcoden oder aber man nutzt das bereits bestehende OWNet.pm und bindet
dieses mittels require ein. Nun wieder das Housekeeping: um solche
"Erweiterungen" von den "Core"-Modulen zu unterscheiden und somit lib (was ja
die "Core"-Module enthält) schön sauber zu halten, kommt OWNet.pm halt nach
lib/site ist aber weiterhin Bestandteil der Distribution, da es von 00_OW.pm
benötigt wird.
> - Es wird irgendwo auch noch modulspezifische Unterverzeichnisse geben
> muessen, siehe die aktuelle HM Diskussionen.
Genau das war ja mit dem site gemeint. Unter lib/site landen die
modulspezifischen Dateien. Somit müsste es auch nicht x-beliebige
Unterverzeichnisse geben, sondern man wüsste das man benötigte Module in
lib/site suchen muß.
Ob das Kind nun "site" oder anders heisst ist mir wurscht (falls der Name oben
zu einer Verwirrung führte).
> - FHEMWEB muss nicht mehr aus FHEM sondern aus lib, lib/site(?), www/doc und
> www/pgm2 Daten zurueckliefern. D.h. die neuen Verzeichnisse muessen
> irgendwo im Programm spezifiziert werden (attr global ...). Entweder
> einzeln, oder als Root-Pfad.
Jain, evtl. überseh ich ja noch was. Aus meiner Sicht muß FHEMWEB nur aus
www/pgm2 Daten liefern. In www/doc lägen ja nur die *.html, die bereits heute
in der Menüleiste lediglich verlinkt sind.
Zu lib und lib/site: Wenn Stand heute in {modpath}/FHEM _nur_ *.pm Module
liegen würden, dann müsstest Du doch auch nichts davon in FHEMWEB
zurückliefern. Oder übersehe ich da was? Ich denke nicht, da ich ja bereits
gestern die Änderung mit pgm2 getestet habe ({modpath}/FHEM enthält nur noch
*.pm und pgm2 liegt in {modpath}/htdocs) und alles läuft. Dazu hatte ich Dir
ja gestern auch ein Patch gesendet mit dem Du die Funktionalität testen
kannst.
> Bitte beachten, dass ich bei fhem bei der
> Entscheidung "einfach oder extrem Konfigurierbar" bisher immer die Loesung
> "einfach" gewaehlt habe.
Bin ich vollkommen bei Dir! Aus meiner Sicht widerspricht mein Vorschlag dem
auch in keinster Weise. Es wird nur aufgeräumter und damit letztlich auch
einfacher, da es klare Grenzen gibt.
So wie ich das sehe resultiert dadurch im Wesentlichen nur folgende Änderung:
- {modpath} bleibt unverändert
- contrib bleibt wie bisher
- FHEM wird umbenannt in lib und enthält nur *.pm Module
- lib/site enthält erweiterte Module (Bestandteil der Distribution) um die
sich fhem.pl nicht kümmern muss, sondern die Module die unter lib liegen.
- pgm2 zieht um nach www/pgm2 (inkl. aller icons, css, etc., Ausnahme
commandref.html, HOWTO.html, etc.)
- www/doc enthält "wiederverwendbare" *.html Dateien (commandref.html,
HOWTO.html, etc. Müsste ggf. noch festgelegt werden welche das final sein
sollen).
> - Diese Liste gilt dann auf fuer fhemupdate bzw. updatefhem.
Das ist richtig! fhemupdate.pl bzw. updatefhem muss dahingehend geändert
werden, das es nicht mehr die Dateien in {modpath}/FHEM checkt, sondern
stattdessen in {modpath}/lib und {modpath}/lib/site.
Zusätzlich muss fhemupdate.pl dahingehend erweitert werden, das die pgm2
Dateien nicht mehr in {modpath}/FHEM gecheckt werden, sondern in
{modpath}/www/pgm2.
> - Doku muss auch angepasst werden, und eine Anleitung fuer migrieren.
Die Doku hatte ich schon bzgl. des ersten Testes mit dem Umzug von pgm2 nach
{modpath}/htdocs angepasst (siehe Patch). Lediglich ein Hinweis, das pgm2 nun
dort liegt ist nicht vorhanden.
Eine Anleitung zur Migration benötigen wir evtl. gar nicht. Da ja alle Dateien
aus pgm2 bekannt sind müssten die nur in das neue Ziel kopiert werden und
bisherigen in {modpath}/FHEM gelöscht werden. Wenn letzteres nicht
(automatisch) gewünscht ist, dann müssten wir die Benutzer nur darauf
aufmerksam machen, das die pgm2 Datein unter {modpath}/FHEM bzw. neu
{modpath}/lib ab dann verwaist sind und er sie dann selber löschen muss. Bei
einem weiteren Update würde diese dann nicht mehr berücksichtigt.
Martin
Martin Fischer
Rudolf Koenig
> und? kommt da noch wat? ;-)
Nicht von mir. Hab zwar ueberlegt ein paar Details anders zu machen, ich glaube
die Diskussion darum ist es mir nicht Wert. Reservier Dir aber Zeit fuer
Support, z.Bsp fuer sowas wie updatefhem beim AVM-image oder das neue
FLOORPLAN. FHEM ist _das_ zentrale fhem Verzeichnis, bin sicher dass es an
mehr Stellen verwendet wird, als mir jetzt einfaellt.
Martin Fischer
Da bin ich doch etwas sehr verwundert!
Erst stellst Du Rückfragen, die ich dann versuche zu erläutern um einen
gemeinsamen Weg zu finden und dann heisst es lapidar: da kommt nichts mehr und
die Diskussion ist es Dir nicht Wert.
Du hast selber geschrieben, das Dir /FHEM zu unübersichtlich wird. Ich habe
angeboten das aufzuräumen, jedoch deutlich gemacht, das ich AVM-images nicht
anfassen werde. Ebenso habe ich um Unterstützung beim updatefhem bzw.
fhemupdate.pl gebeten, da es ein serverseitiges Script bei Dir ist und ich
nicht Deine Serverumgebung kenne.
Eine erste Maßnahme hatte ich bereits unternommen und /FHEM komplett von pgm2
bereinigt. Dies hatte ich Dir als Patch zu testen gesendet worauf leider keine
Reaktion kam.
Da ich Vollzugriff aufs SVN habe, hätte ich es auch einfach mal eben
einchecken können, was ich aber nicht für sinnvoll erachte, wenn man solch
gravierende Änderungen vornimmt. Deshalb habe ich die Diskussion angeregt um
sich gemeinsam Abzustimmen.
Zumindest hat Oskar ja auch seine (aus meiner Sicht) sinnvolle Meinung dazu
geäussert und das zeigt, das es nicht nur Dir und mir, sondern auch weiteren
langsam zu unübersichtlich wird.
Nun denn.. Wenn wir hier also nicht mehr weiter darüber entscheiden wollen,
dann lassen wir es halt so wie es ist. Es erinnert mich doch stark an die
Diskussion die wir seinerzeit zu der ursprünglich geplanten Version 5.0
geführt haben. Also bleibt fhem erstmal weiterhin verwildert und erschwerrt
damit den Zugang zu weiteren Innovationen.
Solch entscheidene Änderungen, besonders in Hinblick auf Updateroutinen, die
auf Deinem Webserver laufen oder die AVM Unterstützung in der Du am tiefsten
von allen steckst, sollten nicht im Alleingang unternommen werden.
Ich verstehe Deine Intention, das Du Dich lieber auf den funktionalen Teil wie
z.B. Homematic konzentrieren möchtest, doch steht der Aufwand zwischen
Reverseengeneering und einer einmaligen Strukturänderung in keinem Verhältnis.
Meiner Meinung nach würden wir (wenn es den gemeinsam unternommen wird) nur
wenig Zeit mit der Umstrukturierung verbringen, dann aber langfristig davon
profitieren können. Homematic dagegen ist eine etwas größere Baustelle, da es
hier um Protokolle und Logik geht.
Seis drum.. meine Meinung dazu kennst Du ja nun schon seit Jahren was die
Öffnung zur Weiterentwicklung von Schnittstellen bzw. APIs in Bezug auf FHEM
angeht. Nur muss dazu auch eine gewisse Grundlage geschaffen werden, die ich
nicht im Alleingang unternehmen werde.
Die Umstellung von pgm2 aus dem /FHEM und die Anpassung des Makefiles hat mich
gerade mal mit testen vielleicht 1 Stunde gekostet.
my 2 cents...
Rudolf Koenig
> Erst stellst Du R�ckfragen, die ich dann versuche zu erl�utern um einen
> gemeinsamen Weg zu finden und dann heisst es lapidar: da kommt nichts mehr und
> die Diskussion ist es Dir nicht Wert.
Dieser Punkt war Dir wichtig, und Du wolltest eine kurze Diskussion haben.
Deswegen wollte ich es nicht in die Laenge ziehen. Ich verliere die Lust an was
zu bauen, wenn man mir haarklein vorschreibt, was ich machen soll, nur ein
"compiler" zu sein schmeckt mir nicht. Das wollte ich Dir auch ersparen, und
Dir die Freiheit lassen. Ich wollte auch nicht die Konsequenzen deiner Ideen
ausbaden, deswegen die Bitte mit dem support.
> Du hast selber geschrieben, das Dir /FHEM zu un�bersichtlich wird.
Stimmt. Nach laengerem Nachdenken waere _mir_ der Umbau nicht Wert.
Aber das heisst nicht, dass andere keine Energie reinstecken sollen. Ich sehe
fhem zunehmend weniger als "meins" an, eher als Gemeinschaftsentwicklung, und
ich bin gewollt eine etwas chaotischere Entwicklung in Kauf zu nehmen, wenn
nicht alles von mir gemacht werden muss.
> Ebenso habe ich um Unterst�tzung beim updatefhem bzw. fhemupdate.pl gebeten,
> da es ein serverseitiges Script bei Dir ist und ich nicht Deine
> Serverumgebung kenne.
fhemupdate.pl kann ich gerne uebernehmen, obwohl man das mit einem beliebigen
web/ftp-server auch simulieren kann. Aber das zeigt auch mein Problem:
jemand hat eine nette Idee, baut es irgendwo ein, wo es kein grosser Aufwand
ist, und ihm selber gerade hilft, und an mir bleibt die "dreckige" Arbeit an
obstrusen Faellen, support, etc.
Ich habe absolut kein Problem damit, wenn jemand was (sinnvolles) aendert, und
von vorne bis hinten alles bedenkt/uebernimmt. Und ich mich wie ein Benutzer
nur noch ueber die Aenderung freuen kann, und mich womoeglich bei Problemen
beschweren kann.
> Es erinnert mich doch stark an die Diskussion die wir seinerzeit zu der
> urspr�nglich geplanten Version 5.0 gef�hrt haben.
Da war auch anderen etwas wichtig, und nach der Entscheidung haben alle auf
Rudi gewartet, dass das gewuenschte implementiert wird. Fhem ist fuer mich
immer noch Freizeit, wo ich nicht (nur) das mache, was andere wuenschen. Ich
will aber keinen abhalten: also bitte nicht frustiert werden, sondern fuer den
eigenen Wunsch bzw. Entscheidung die Konsequenzen uebernehmen.
Gruss,
Rudi
Martin Fischer
ich glaube, hier wird etwas durcheinander geschmissen..
Am Dienstag, 13. März 2012, 09:13:50 schrieb Rudolf Koenig:
> Dieser Punkt war Dir wichtig, und Du wolltest eine kurze Diskussion haben.
> Deswegen wollte ich es nicht in die Laenge ziehen. Ich verliere die Lust an
> was zu bauen, wenn man mir haarklein vorschreibt, was ich machen soll, nur
> ein "compiler" zu sein schmeckt mir nicht. Das wollte ich Dir auch
> ersparen, und Dir die Freiheit lassen. Ich wollte auch nicht die
> Konsequenzen deiner Ideen ausbaden, deswegen die Bitte mit dem support.
Genau dazu sollte ja die Diskussion dienen: Keinem sollte haarklein
vorgeschrieben werden, wie er etwas machen soll. Es sollte dazu dienen eine
_gemeinsame_ Basis zu finden wie das Thema am Besten umgesetzt werden kann.
Schade das Du daran die Lust verlierst, _gemeinsam_ den richtigen Weg zu
finden.
> Stimmt. Nach laengerem Nachdenken waere _mir_ der Umbau nicht Wert.
> Aber das heisst nicht, dass andere keine Energie reinstecken sollen. Ich
> sehe fhem zunehmend weniger als "meins" an, eher als
> Gemeinschaftsentwicklung, und ich bin gewollt eine etwas chaotischere
> Entwicklung in Kauf zu nehmen, wenn nicht alles von mir gemacht werden
> muss.
Auch hier liegt meiner Meinung nach ein Missverständnis vor: Keiner hat
erwartet, das Du alles machen mußt! So wie Du es siehst, denke ich das es in
die richtige Richtung geht: es ist zunehmend ein Gemeinschaftsprojekt.
> fhemupdate.pl kann ich gerne uebernehmen, obwohl man das mit einem
> beliebigen web/ftp-server auch simulieren kann. Aber das zeigt auch mein
> Problem: jemand hat eine nette Idee, baut es irgendwo ein, wo es kein
> grosser Aufwand ist, und ihm selber gerade hilft, und an mir bleibt die
> "dreckige" Arbeit an obstrusen Faellen, support, etc.
Moment! Auch hier verstehst Du glaub ich etwas falsch! Konkret zum Thema
Housekeeping habe ich dadurch keine persönlichen Vorteile geschweige denn, das
es "mir gerade selber" hilft. Ich kann damit leben, das im Verzeichniss /FHEM
Wildwuchs herrscht. Die Frage die ich mir aber gestellt habe: geht es
vielleicht auch sauberer. Kann / sollte man evtl. zur besseren Übersicht und
letztlich auch zum besseren Verständnis von FHEM nicht den rein funktionellen
Teil (die Module) von der Darstellungsschicht (pgm2, Floorplan, etc.) trennen?
Ein Bespiel: Du nutzt in pgm2 ein icon, das Haus.pgm heisst. Nun kommt ein
Benutzer der im Floorplan ein Grundriss namens Haus.pgm nutzen will. Welches
Datei soll er dann umbenennen? Muss der Anwender ggf. in Kauf nehmen, das
diese "Freiheit" dazu führt, das beim nächsten updatefhem, sein Grundriss
überschrieben wird? Müssen wir dann damit Leben, das in der Usergroup
anfängertypische Fragen gestellt werden wie "Mein Haussymbol wird nicht mehr
angezeigt" oder "Mein Grundriss ist weg".
Deshalb habe ich etwas über den Tellerrand geblickt und in die Zukunft
geschaut, wie man solch Probleme bereits im Vorfeld weitestgehends
ausschliessen kann ohne das der "Dreck" wieder an Rudi kleben bleibt.
In dieser Hinsicht hast Du mich komplett falsch verstanden! Meine Intention
liegt eher in die Richtung: wie kann man den Support-Aufwand verringern und
den Entwickler einen gewissen Standard vorgeben.
> Ich habe absolut kein Problem damit, wenn jemand was (sinnvolles) aendert,
> und von vorne bis hinten alles bedenkt/uebernimmt. Und ich mich wie ein
> Benutzer nur noch ueber die Aenderung freuen kann, und mich womoeglich bei
> Problemen beschweren kann.
Jain.. da gebe ich Dir zum Teil recht. Wenn ich eine funktionale Änderung
vornehme, die Du selber als Benutzer nutzt, dann sollte das so wie Du
schreibst sein.
Hierbei geht es jedoch um eine Gesamtstruktur. Und wie Du selbst eingangs
schriebst, möchtest Du nicht als "compiler" benutzt werden oder gar einfach
vorgschrieben bekommen, wie Du was zu tun hast. Und genau deshalb habe ich ja
die Diskussion gestartet: Wie kommen wir _gemeinsam_ zu einem Ergebniss, das
a) keine allzu grosse Umstellung für die Entwickler darstellt, ihnen b) auch
noch die Freiheiten läßt aber c) einen gewissen Rahmen vorgibt um FHEM
"sauber" zu halten.
Und da es sich bei dem "Housekeeping" nicht einfach nur um eine Änderung /
Erweiterung / Neuerung einer Funktion, sondern es sich wie bereits geschrieben
um eine "strukturelle Änderung" handelt, sollte das aus meiner Sicht eben
nicht im Alleingang unternommen werden.
> Da war auch anderen etwas wichtig, und nach der Entscheidung haben alle auf
> Rudi gewartet, dass das gewuenschte implementiert wird. Fhem ist fuer mich
> immer noch Freizeit, wo ich nicht (nur) das mache, was andere wuenschen. Ich
> will aber keinen abhalten: also bitte nicht frustiert werden, sondern fuer
> den eigenen Wunsch bzw. Entscheidung die Konsequenzen uebernehmen.
Auch da muss ich Dir widersprechen (zumindest spreche ich da für meine
Person). _Ich_ habe nicht darauf gewartet, das _Du_ das implementierst,
sondern das _Du_ mit im Boot bist. Die Änderungen hätten zur Folge gehabt, das
wir fhem.pl _und_ Module hätten anpassen müssen. Es wurde, zumindest aus
meiner Sicht, darauf gewartet, _wer_ welchen Part übernimmt und nicht, wann
wird Rudi das machen. Nur hätten wir nicht einfach anfangen können, Module
anzupassen wenn Du z.B. Teile von fhem.pl nicht anpassen würdest (oder
andersum). So haben das - glaube ich - auch andere gesehen, nach dem Motto:
Wenn Rudi überhaupt nicht dabei ist und unterstützt, brauchen wir nicht
anfangen.
Rudi, ich glaube Du siehst da etwas zu sehr schwarz/weiss! Keiner _verlangt_
von Dir bei einem "gemeinschaftlichen Freizeitprojekt", das Du die ganze
Arbeit machst. Wenn jemand so denkt, dann gehört er "verhauen" ;-) Aber
andersrum kannst Du auch nicht erwarten, das andere mal eben im Alleingang
wesentliche strukturelle, architektonische Ändern durchführen ohne sich
gemeinsam abzustimmen. Das hätte dann wieder zur Folge, das man Dir
vorschreibt, wie Du zu Programmieren hast ohne sich abzustimmen.
Wenn Du Dich z.B. nur auf die funktionelle Weiterentwicklung konzentrierst und
ich z.B. nebenbei die ganze Struktur ändern würde oder von mir aus die ganze
Lokalisierung umsetzen würde, dann würde unserer Code schnell auseinander
laufen und schwieriger wieder zusammen zu führen sein.
Wenn wir aber eine Arbeitsteilung vornehmen und Du für den Zeitraum der
strukturellen Änderung Deine funktionelle Weiterentwicklung kurz onhold setzt,
dann würde man schneller zum Ziel kommen und aus meiner Sicht auch langfristig
davon was haben.
Im Übrigen bin ich weder frustiert, noch will ich hier _meinen_ Wunsch oder
_meine_ Entscheidung durchboxen. Ich habe mir lediglich Gedanken gemacht, Dir
dazu meine Hilfe angeboten Teile davon zu übernehmen und den Versuch gestartet
_gemeinsam_ einen gangbaren Weg zu finden.
Nochmals: ICH kann damit leben wie es ist. Nur vertrete ich die Meinung, das
der Support-Aufwand sich dadurch in Zukunft nicht verringern wird und
letztlich wieder jeder der Meinung ist "Rudi wird das schon schaukeln".
Und nochmal auf fhemupdate.pl / updatefhem zurück: Klar kann ich das auch
machen und mir das anschauen. Mein Grundgedanke war jedoch das Du den Code
dort am Besten kennst und diese Änderung Dir wahrscheinlich schneller und
leichter von der Hand gehen würde bevor ich mir erst die richtige Umgebung
einrichte. Was ich (zum wiederholten Male) nicht anfassen würde ist der ganze
AVM Kram. Einfach aus dem Prinzip herraus, das meine Boxen Internet
bereitstellen sollen und weiter nichts. Und das der Support durch die
Integration auch Fritz!Box so hoch ist, zeigt doch auch was dort noch zum Teil
für Probleme vorliegen ohne das im Einzelnen beurteilen zu können und wollen.
Da kennst Du Dich denke ich am Besten mit aus. Und ich kann mir nicht
vorstellen, das es ein riesen Problem für die Fritzboxen darstellt, wenn
unterhalb von {contrib} nun nicht mehr nur /FHEM sondern auch andere
Verzeichnisse genutzt werden. Nur muss es halt ins image!
Gruss Martin
Rudolf Koenig
Ok, da liegt die unterschiedliche Wahrnehmung: ich dachte Du machst es, und Du
dachtest, wir machen es gemeinsam. Da ich mein naechstes Wochenende nicht mit
testen der umsortierten Dateien verbringen will, bleibt mein Angebot auf
fhemupdate.pl begrenzt.
Sag Bescheid, ob bzw. wann ich fhemupdate.pl umstellen soll.
Martin Fischer
> [...] bleibt mein
> Angebot auf fhemupdate.pl begrenzt.
>
> Sag Bescheid, ob bzw. wann ich fhemupdate.pl umstellen soll.
Ich schlage vor im ersten Schritt lediglich pgm2 (so wie im Patch) zu
verlegen. Dazu muss fhemupdate.pl angepasst werden. Gerne kann ich da auch
noch Teile von übernehmen, wenn klar ist was und wie.
Wir sollten uns jedoch vorher überlegen, wie wir das mit dem Update angehen.
Wenn wir dazu eine Strategie abgestimmt haben, bin ich gerne bereit den
Support zu übernehmen. Aber das bedingt eben, das wir uns _vorher_ über die
Vorgehensweise einig sind und diese dann nach der Umsetzung auch getestet
wird, bevor wir das einchecken.
Verschieben / update der Dateien
a) manuell durch Benutzer
b) semiautomatisch (z.B. durch ein von benutzer zu setzendes flag bei
updatefhem)
c) vollautomatisch
Weiterhin sollten wir uns noch kurz abstimmen in welches Verzeichnis pgm2
"umziehen" soll. Per default in {modpath}/www/pgm2 und das dann konfigurierbar
machen? Wobei letzteres evtl. über fwmodpath möglich wäre.
Jan-Hinrich Fessel
Am 13.03.2012 um 16:45 schrieb Martin Fischer:
> Am Dienstag, 13. März 2012, 13:34:14 schrieb Rudolf Koenig:
>> [...] bleibt mein
>> Angebot auf fhemupdate.pl begrenzt.
>>
>> Sag Bescheid, ob bzw. wann ich fhemupdate.pl umstellen soll.
>
> Ich schlage vor im ersten Schritt lediglich pgm2 (so wie im Patch) zu
> verlegen. Dazu muss fhemupdate.pl angepasst werden. Gerne kann ich da auch
> noch Teile von übernehmen, wenn klar ist was und wie.
>
> Wir sollten uns jedoch vorher überlegen, wie wir das mit dem Update angehen.
> Wenn wir dazu eine Strategie abgestimmt haben, bin ich gerne bereit den
> Support zu übernehmen. Aber das bedingt eben, das wir uns _vorher_ über die
> Vorgehensweise einig sind und diese dann nach der Umsetzung auch getestet
> wird, bevor wir das einchecken.
>
> Verschieben / update der Dateien
> a) manuell durch Benutzer
> b) semiautomatisch (z.B. durch ein von benutzer zu setzendes flag bei
> updatefhem)
> c) vollautomatisch
b++) bzw. c--)
Das Problem ist, das updatefhem sowohl maschinell (per cron/fhem at) als auch interaktiv (im webfrontend) benutzt wird. Wenn es nur interaktiv genutzt wird, wäre es ja einfach, dann würde halt einfach ein popup generiert werden mit dem Hinweis, das was verschoben werden sollte (OK - Jetzt noch nicht).
Bei automatisch hängt das dann etwas blöd in der Luft.
Also eigentlich sinnvollerweise vollautomatisch, bei Fehlern eine prominente Mitteilung auf der Webseite (pgm2).
Blöd wäre manuell, dann kriegt man das nie konsistent.
>
> Weiterhin sollten wir uns noch kurz abstimmen in welches Verzeichnis pgm2
> "umziehen" soll. Per default in {modpath}/www/pgm2 und das dann konfigurierbar
> machen? Wobei letzteres evtl. über fwmodpath möglich wäre.
Das würde ich unterstützen.
Schöne Grüße
Oskar
Rudolf Koenig
Manuell ist der Mehrheit nicht zuzumuten, und da viele Doku/Newsgroup nicht
konsequent lesen, ist ein Flag nur dann sinnvoll, wenn die bisherige Syntax ein
Fehler meldet. Und selbst das wird manche, die updatefhem per "at" ausfuehren,
ueberraschen (eigentlich selbst schuld).
> Per default in {modpath}/www/pgm2 und das dann konfigurierbar
> machen? Wobei letzteres evtl. �ber fwmodpath m�glich w�re.
Ich wuerde in updatefhem nur {modpath}/www/pgm2 einbauen. fwmodpath ist
FHEMWEB-Instanz abhaengig, und ist mit updatefhem nicht kompatibel. Ist ein
Weg, seine "eigenen" Dateien von einem automatischen update zu schuetzen.
Wenn ich dazukomme aendere ich fhemupdate.pl so, dass es Daten nach
fhem.de/fhemupdate2 hochlaedt, dieser hat dann die neue Struktur, zuerst also
fhemupdate2/FHEM, fhemupdate2/www/pgm2 und fhemupdate2/www/doc
Martin Fischer
> [...]
> fhem.de/fhemupdate2 hochlaedt, dieser hat dann die neue Struktur, zuerst
> also fhemupdate2/FHEM, fhemupdate2/www/pgm2 und fhemupdate2/www/doc
Ja, wäre doch ok. pgm2 habe ich soweit angepasst, sehe nicht das ich was
vergessen habe. Müssen wir uns nur noch abstimmen, wann wir den Schritt wagen.
Martin Fischer
> [...]
>
> Das würde ich unterstützen.
Danke Oskar. Ich denke wir werden da erstmal schrittweise vorgehen und erstmal
nur pgm2 "umziehen". Später kann man sich dann noch Gedanken machen, das noch
konfigurierbarer zu machen.
Martin
Martin Fischer
> [...]
> fhem.de/fhemupdate2 hochlaedt, dieser hat dann die neue Struktur, zuerst
> also fhemupdate2/FHEM, fhemupdate2/www/pgm2 und fhemupdate2/www/doc
lass mal bitte fhemupdate2/www/doc weg. die dateien (commandref.html,
HOWTO.html, etc...) packe ich auch in fhemupdate2/www/pgm2, da es sonst
probleme gibt mit der anzeige von grafiken innerhalb der dateien.
Rudolf Koenig
> HOWTO.html, etc...) packe ich auch in fhemupdate2/www/pgm2, da es sonst
> probleme gibt mit der anzeige von grafiken innerhalb der dateien.
Hab ein fhemupdate.pl gebaut, der parallel zum alten fhem.de/fhemupdate
Verzeichnis ein neues fhem.de/fhemupdate2 befuellt mit einem FHEM und einem
www/pgm2 Unterverzeichnis.
Gruss,
Rudi
Martin Fischer
wann wollen wir die änderungen zusammenführen? soll ich die änderungen
einchecken?
UliM
mein erster post in diesem Forum... Gerne möchte ich mit einem wiederholten Dank an alle fhem-Entwickler starten :)
Seit gestern meldet nun der zweite user:
- updatefhem + shutdown restart ausgeführt
- dennoch läuft floorplan auf Poller, mit Log-Meldungen die zeigen, dass eine nicht aktuelle 01_FHEMWEB.pm heruntergeladen wurde (eine Version, in der einige Variablen noch nicht als global definiert sind).
Natürlich bin ich nicht sicher, was die user wirklich machen. Falls jedoch bereits an der Umstellung von updatefhem gebaut wird, hiermit der Hinweis, dass derzeit möglicherweise nicht-aktuelle Programmstände (zumindest von 01_FHEMWEB.pm) verteilt werden.
Gruß, Uli
Martin Fischer
Am Sonntag, 18. März 2012, 11:11:17 schrieb UliM:
> mein erster post in diesem Forum... Gerne möchte ich mit einem
> wiederholten Dank an alle fhem-Entwickler starten :)
Danke dafür!
> Seit gestern meldet nun der zweite user:
> - updatefhem + shutdown restart ausgeführt
> - dennoch läuft floorplan auf Poller, mit Log-Meldungen die zeigen, dass
> eine nicht aktuelle 01_FHEMWEB.pm heruntergeladen wurde (eine Version, in
> der einige Variablen noch nicht als global definiert sind).
Ich kann das jetzt nicht nachvollziehen. Zumal in 01_FHEMWEB.pm keine neuen
Variablen verpasst bekommen hat sondern lediglich der pfad für pgm2 von FHEM
auf www/pgm2 geändert wurde. Das betrifft nur eine einzige Zeile:
- $FW_dir = AttrVal($FW_wname, "fwmodpath", "$attr{global}{modpath}/FHEM");
+ $FW_dir = AttrVal($FW_wname, "fwmodpath", "$attr{global}
{modpath}/www/pgm2");
Das habe ich aber erst gegen 21:00 Uhr eingecheckt.
> Natürlich bin ich nicht sicher, was die user wirklich machen. Falls jedoch
> bereits an der Umstellung von updatefhem gebaut wird, hiermit der Hinweis,
> dass derzeit möglicherweise nicht-aktuelle Programmstände (zumindest von
> 01_FHEMWEB.pm) verteilt werden.
Ich habe gerade fhem-5.2 installiert und ein Update durchgeführt. Dann habe
ich auch mal FLOORPLAN installiert wieder ein Update durchgeführt und alles
läuft.
So kann ich im Moment keinen Zusammenhang feststellen.
Gruß Martin
Martin Fischer
> wann wollen wir die änderungen zusammenführen? soll ich die änderungen
> einchecken?
da ich gesehen habe, das du das neue fhemupdate.pl schon eingecheckt hast,
habe ich meine änderungen auch commited.
anpassungen in
01_FHEMWEB.pm
Makefile
CHANGED
commandref.html
Martin Fischer
hat bei mir nicht geklappt. ich habe fhem aus dem svn installiert (mit meinen
änderungen). pgm2 liegt in {modpath}/www/pgm2 und {modpath}/FHEM enthält nur
die module.
nach einem updatefhem landen alle dateien aus pgm2 wieder im {modpath}/FHEM.
ich finde allerdings nicht den fehler in fhemupdate.pl
UliM
Am Freitag, 9. März 2012 21:36:02 UTC+1 schrieb Martin Fischer:
Um FHEM nun etwas mehr zu strukturieren (in Hinblick auf die künftigeEntwicklung) habe ich mir folgendes überlegt:
/usr/share/fhem
/usr/share/fhem/contrib
/usr/share/fhem/lib (Optional modules)
/usr/share/fhem/lib/site (Optional modules/site)
/usr/share/fhem/locale
/usr/share/fhem/locale/de_DE
/usr/share/fhem/locale/en_EN
/usr/share/fhem/www
/usr/share/fhem/www/doc
/usr/share/fhem/www/pgm2
grundsätzlich find ich so eine Aufräumaktion sehr gut.
Die übliche Krux: strukturiert man die Verzeichnisse (a) nach "Dokumentarten" (wie hier) oder (b) nach "Produkten" (also einen Ordner je Programm, in dem dann auch die zugehörige Doku liegt).
95_FLOORPLAN soll demnächst umziehen von contrib nach pgm2. Zielstruktur ist (a), für floorplan hab ich mangels besseren Wissens (b) gewählt (siehe hier) und stelle mir die Frage, wie man das am sinnvollsten überführt.
Wenn's dann mal so weit ist - meine Vorschlag:
95_FLOORPLAN.pm -> /usr/share/fhem/www/pgm2
99_myFloorplanList.pm -> /usr/share/fhem/contrib
commandref - floorplan.html -> obsolet, da nun in der Gesamt-commandref.html enthalten
floorplanstyle.css -> /usr/share/fhem/www/pgm2
darkfloorplanstyle.css -> /usr/share/fhem/www/pgm2
fhem-floorplan-installation-guide.pdf -> /usr/share/fhem/www/doc
fhem-floorplan-installation-guide_de.pdf -> /usr/share/fhem/www/doc
Das Ganze muss dann zukünftig zusammengehalten werden durch 1. entsprechende Verweise/Links im entspr. commandref-Eintrag, 2. ebensolche Verweise in fhem-floorplan-installation-guide*.pdf
Passt das so, oder hat jemand nen anderen Vorschlag?
Und dann noch die Frage:
/usr/share/fhem/locale
/usr/share/fhem/locale/de_DE
/usr/share/fhem/locale/en_EN
Gibt es einen Grund, warum hier locale (Schauplatz) verwendet werden soll statt local oder locl ?
Gruß, Uli
Jan-Hinrich Fessel
Am 19.03.2012 um 09:15 schrieb UliM:
> Und dann noch die Frage:
> /usr/share/fhem/locale
> /usr/share/fhem/locale/de_DE
> /usr/share/fhem/locale/en_EN
> Gibt es einen Grund, warum hier locale (Schauplatz) verwendet werden soll statt local oder locl ?
Wei traditionell bei Unixen die Lokalisierungen (also sprachspezifischen Daten) unter .../locale/ stehen. Denn es handelt sich nicht um lokale Daten, sondern um ortsspezifische, also lokalisierte Daten.
Genaueres womöglich in der Wikipedia...
Grüße
Oskar
Rudolf Koenig
> ich finde allerdings nicht den fehler in fhemupdate.pl
Ich habe nur fhemupdate.pl geaendert, updatefhem & co (samt verschieben) bleibt
jemanden sonst ueberlassen.
Rudolf Koenig
Mit dem Ergebnis, dass nach einem updatefhem FHEMWEB nicht mehr funktioniert:
das ist ein NO-GO. Ich habe die www/pgm2 Zeile in 01_FHEMWEB.pm wieder auf FHEM
gestellt, eingecheckt, und fhemupdate.pl durchgefuehrt. Ich hoffe dass in der
Zwischenzeit (heute 7:45 bis jetzt) keiner ein updatefhem durchgefuehrt hat.
Bitte nur dann etwas in SVN einchecken, wenn es auch funktioniert. Ich hoffe
dass bis zum Fix das geaenderte commandref.html bzw. Makefile nicht zu viele
Leute verstoert.
Martin Fischer
vielleicht hätten wir uns dazu _vorher_ mal so direkt abstimmen können. dann
hätte ich auch den rest auch noch nicht eingecheckt!
ich bin davon ausgegangen, das die updategeschichte als ganzes von dir
betrachtet wird. also das updatefhem bestandteil von fhemupdate.pl ist.
nun gut..
ich rolle das nun zurück, bis wir den rest geklärt haben.. mir ist. z.b. dein
zusatz "& co" nicht klar. ebenso was dein fhemupdate.pl nun genau macht. es
wär gut, wenn du dazu ein "paar worte" mehr hinterlassen könntest.
Martin Fischer
> [...]
> Wenn's dann mal so weit ist - meine Vorschlag:
> 95_FLOORPLAN.pm -> /usr/share/fhem/www/pgm2
> 99_myFloorplanList.pm -> /usr/share/fhem/contrib
> commandref - floorplan.html -> obsolet, da nun in der
> Gesamt-commandref.html enthalten
> floorplanstyle.css ->
> /usr/share/fhem/www/pgm2
> darkfloorplanstyle.css ->
> /usr/share/fhem/www/pgm2
> fhem-floorplan-installation-guide.pdf -> /usr/share/fhem/www/doc
> fhem-floorplan-installation-guide_de.pdf -> /usr/share/fhem/www/doc
> Das Ganze muss dann zukünftig zusammengehalten werden durch 1.
> entsprechende Verweise/Links im entspr. commandref-Eintrag, 2. ebensolche
> Verweise in fhem-floorplan-installation-guide*.pdf
> Passt das so, oder hat jemand nen anderen Vorschlag?
die idee ist ja, das module von "nichtmoduldateien" getrennt werden. demnach
sehe ich 95_FLOORPLAN.pm in dem (jetzigen) {modpath}/FHEM verzeichnis und
nicht im {modpath}/www/pgm2.
das {modpath}/www/doc verzeichnis sehe ich im moment noch problematisch, da
01_FHEMWEB.pm das so noch nicht beherrscht und da erstmal Brainstorming
betrieben werden muss.
die anderen von dir aufgeführten dateien (*.css) _könnten_ in
{modpath}/www/pgm2 liegen, wenn der umzug von pgm2 fertig ist. solange der
umzug noch nicht abgeschlossen ist, würden alle dateien von FLOORPLAN aktuell
ins {modpath}/FHEM gehören (ausnahme ggf. die *.pdf datein, die würden nach
/usr/share/doc/fhem gehören und die 99_myFloorplanList.pm in ein FLOORPLAN
unterverzeichnis in contrib, sofern dieses modul nur optional zu nutzen ist.
wenn 99_myFloorplanList.pm von 95_FLOORPLAN.pm explizit benötigt wird, dann
sollte es ebenfalls zu den modulen nach {modpath}/FHEM)
> Und dann noch die Frage:
> /usr/share/fhem/locale
> /usr/share/fhem/locale/de_DE
> /usr/share/fhem/locale/en_EN
> Gibt es einen Grund, warum hier locale (Schauplatz) verwendet werden soll
> statt local oder locl ?
das hat oskar ja schon richtig erläutert. hierbei geht es um
sprachlokalisierung. die idee dahinter: irgendwann fhem soweit zu
modifizieren, das man in der config festlegen kann ob die ausgaben in einer
anderen sprache erfolgen soll. also bei de_DE "Temperatur", "An", "Aus" und
bei en_EN "Temperature", "On", "Off". dann könnte man noch weitere sprachen
einbinden, wenns denn erwünscht ist.
martin
Rudolf Koenig
> betrachtet wird. also das updatefhem bestandteil von fhemupdate.pl ist.
Mag sein, testen sollte man aber trotzdem, ich haette ja auch Unfug einchecken
koennen. fhemupdate.pl habe ich nur uebernommen, damit Du das Einrichten eines
webservers samt ftp upload sparst, von uploadfhem habe ich nie geredet.
> mir ist. z.b. dein zusatz "& co" nicht klar.
Alles was durch den Umbau von FHEM nach lib, www/pgm2, etc betroffen ist.
Ausser fhemupdate.pl, den habe ich ja jetzt an der Backe.
> ebenso was dein fhemupdate.pl nun genau macht.
Laedt taeglich die Aenderungen aus dem SVN nach fhem.de/fhemupdate/*, und seit
gestern parallel dazu nach
fhem.de/fhemupdate2/filetimes.txt
fhem.de/fhemupdate2/fhem.pl.txt
fhem.de/fhemupdate2/FHEM/*
fhem.de/fhemupdate2/www/pgm2/*
Was wo zu suchen ist, steht im filetimes.txt.
Martin Fischer
> > ich bin davon ausgegangen, das die updategeschichte als ganzes von dir
> > betrachtet wird. also das updatefhem bestandteil von fhemupdate.pl ist.
>
> Mag sein, testen sollte man aber trotzdem, ich haette ja auch Unfug
> einchecken koennen. fhemupdate.pl habe ich nur uebernommen, damit Du das
> Einrichten eines webservers samt ftp upload sparst, von uploadfhem habe ich
> nie geredet.
du wirst es nicht glauben: ich habe es getestet und komischerweise lief es bei
mir. siehe auch:
Am Sonntag, 18. März 2012, 21:41:39 schrieb Martin Fischer:
> Ich kann das jetzt nicht nachvollziehen. Zumal in 01_FHEMWEB.pm keine neuen
> Variablen verpasst bekommen hat sondern lediglich der pfad für pgm2 von FHEM
> auf www/pgm2 geändert wurde. Das betrifft nur eine einzige Zeile:
>
> - $FW_dir = AttrVal($FW_wname, "fwmodpath", "$attr{global}{modpath}/FHEM");
> + $FW_dir = AttrVal($FW_wname, "fwmodpath", "$attr{global}
> {modpath}/www/pgm2");
>
> Das habe ich aber erst gegen 21:00 Uhr eingecheckt.
>
> > Natürlich bin ich nicht sicher, was die user wirklich machen. Falls jedoch
> > bereits an der Umstellung von updatefhem gebaut wird, hiermit der Hinweis,
> > dass derzeit möglicherweise nicht-aktuelle Programmstände (zumindest von
> > 01_FHEMWEB.pm) verteilt werden.
>
> Ich habe gerade fhem-5.2 installiert und ein Update durchgeführt. Dann habe
> ich auch mal FLOORPLAN installiert wieder ein Update durchgeführt und alles
> läuft.
und das mit dem updatefhem kam daher, das ich das folgende wohl
missinterpretiert habe:
Am Mittwoch, 14. März 2012, 08:50:16 schrieb Rudolf Koenig:
> [...]
> Ich wuerde in updatefhem nur {modpath}/www/pgm2 einbauen. fwmodpath ist
> FHEMWEB-Instanz abhaengig, und ist mit updatefhem nicht kompatibel. Ist ein
> Weg, seine "eigenen" Dateien von einem automatischen update zu schuetzen.
das las sich für mich, als wenn du es dort auch einbaust.
anyway! es geht hier ja auch nicht darum den schuldigen zu finden, sondern wie
wir das umsetzen. es gab missverständnisse und nun sollten wir uns wieder auf
die aufgabe konzentrieren.
> > mir ist. z.b. dein zusatz "& co" nicht klar.
>
> Alles was durch den Umbau von FHEM nach lib, www/pgm2, etc betroffen ist.
> Ausser fhemupdate.pl, den habe ich ja jetzt an der Backe.
gut, das ist soweit klar. das mit FHEM nach lib sollte in einem zweiten
schritt passieren um erstmal bei den modulen etwas aufzuräumen. das schrieb
ich ja auch schon:
Am Freitag, 16. März 2012, 20:53:56 schrieb Martin Fischer:
> Danke Oskar. Ich denke wir werden da erstmal schrittweise vorgehen und
> erstmal nur pgm2 "umziehen". Später kann man sich dann noch Gedanken
> machen, das noch konfigurierbarer zu machen.
was mir aber an dem "& co" noch unklar ist, was den umzug von pgm2 nach
{modpath}/www/pgm2 angeht im zusammenhang mit den fritzbox images. hier _kann_
ich nicht unterstützen, bzw. abschätzen ob das was bricht. siehst du noch
andere punkte die du oben unter "Alles was betroffen ist" (nur auf pgm2
bezogen) noch in frage kämen?
> > ebenso was dein fhemupdate.pl nun genau macht.
>
> Laedt taeglich die Aenderungen aus dem SVN nach fhem.de/fhemupdate/*, und
> seit gestern parallel dazu nach
> fhem.de/fhemupdate2/filetimes.txt
> fhem.de/fhemupdate2/fhem.pl.txt
> fhem.de/fhemupdate2/FHEM/*
> fhem.de/fhemupdate2/www/pgm2/*
> Was wo zu suchen ist, steht im filetimes.txt.
ok, prima. dann schaue ich mir updatefhem an. bleibt nur noch die frage,
welchen weg wir da gehen sollten.
aktuell ist updatefhem ja wie folgt definiert:
updatefhem [backup] [filename]
denkbar wäre z.b.
updatefhem führt ein update aus, prüft ob {modpath}/www/pgm2 vorhanden ist,
wenn nein -> anlegen und packt alle pgm2 dateien in die neue struktur. danach
wird automatisch ein backup vom {modpath}/FHEM unter einem vorgegebenem namen
durchgeführt um die "alten" dateien zu sichern. anschliessend werden alle
pgm2-dateien aus {modpath}/FHEM automatisch gelöscht und die meldung "shutdown
restart notwendig" ausgegeben.
oder man lässt das löschen weg und spendiert updatefhem einen neuen flag wie
updatefhem [backup|cleanpgm2] [filename]. so lange kein "updatefhem cleanpgm2"
aufgerufen wird, bleiben die dateien in {modpath}/FHEM unangetastet. fhem
arbeitet aber schon mit {modpath}/www/pgm2
andere ideen?
martin
Rudolf Koenig
- Fhemweb bietet das editieren von "$FW_dir/.*(sh|Util.*|cfg|holiday)" an, das
waere z.T. weg.
- den Edit Abschnitt mit den examples habe ich gerade entfernt, war eh nicht
mehr verlinkt.
Was anderes faellt mir nicht ein.
> denkbar w�re z.b.
Ich finde beide Loesungen akzeptabel, waere selber eher fuer die manuelle
loesung, da vmtl. einfacher zu implementieren.
Jan-Hinrich Fessel
Leider ist dafür wahrscheinlich etwas Arbeit am updatefhem.pl/fhemupdate.pm nötig, damit die Sachen aus dem Branch auch genommen werden, wenn die Branch-Version zum testen genommen wird. Also den Branch an eine andere Stelle hochsyncen und da ein neues fhemupdate ablegen. Oder so.
Für mich persönlich ist updatefhem zu unflexibel, ich mach das alles direkt aus dem svn. Da aber wahrscheinlich auf der Fritzbox kein svn vorhanden ist, würde sich ein Umschreiben von updatefhem auch nicht lohnen.
Grüße
Oskar
Am 19.03.2012 um 17:49 schrieb Rudolf Koenig:
>> siehst du noch andere punkte die du oben unter "Alles was betroffen ist" (nur
>> auf pgm2 bezogen) noch in frage kämen?
>
> - Fhemweb bietet das editieren von "$FW_dir/.*(sh|Util.*|cfg|holiday)" an, das
> waere z.T. weg.
> - den Edit Abschnitt mit den examples habe ich gerade entfernt, war eh nicht
> mehr verlinkt.
>
> Was anderes faellt mir nicht ein.
>
>
>
>> denkbar wäre z.b.
>
> Ich finde beide Loesungen akzeptabel, waere selber eher fuer die manuelle
> loesung, da vmtl. einfacher zu implementieren.
>
> --
> Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe FHEM developers beigetreten sind.
> Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-de...@googlegroups.com.
> Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-develope...@googlegroups.com.
> Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-developers?hl=de, um weitere Optionen zu erhalten.
>
Boris Neubert
wie ging denn die ganze Diskussion aus?
Ich bin gerade dabei, WeatherAsHtmlLocal zu integrieren, und will die
dafür erforderlichen Icons gesondert ablegen, um {modpath}/FHEM nicht
weiter vollzumüllen.
{modpath}/share/icons/weather
wäre für mich intuitiv der Ort der Wahl. Bevor ich jetzt vollendete
Tatsachen schaffe und entweder die Nachwelt zu
{modpath}/share/icons zwinge oder die Verzeichnisstruktur balkanisiere
möchte ich das nochmal zur Diskussion stellen.
Grüße
Boris
Martin Fischer
Am Samstag, 19. Mai 2012, 01:50:37 schrieb Boris Neubert:
> wie ging denn die ganze Diskussion aus?
das neue 99_updatefhem.pm ist soweit fertig und wird gerade noch
qualitätsgesichert. rudi und ich testen es auf verschiedenen OS (wegen tar,
etc.). mein ziel ist, es noch dieses wochenende einzuchecken.
pgm2 landet dann unter $modtpath/www/pgm2
> Ich bin gerade dabei, WeatherAsHtmlLocal zu integrieren, und will die
> dafür erforderlichen Icons gesondert ablegen, um {modpath}/FHEM nicht
> weiter vollzumüllen.
auch nur noch *.pm, *.sh, *.cfg, *.holiday landen sollen.
obwohl mir da immer noch eine sauberere struktur für $modpath vorschwebt
('lib' statt 'FHEM' für *.pm, 'bin' für *.sh, 'etc' für *.cfg|*.holiday)
> {modpath}/share/icons/weather
>
> wäre für mich intuitiv der Ort der Wahl. Bevor ich jetzt vollendete
> Tatsachen schaffe und entweder die Nachwelt zu
> {modpath}/share/icons zwinge oder die Verzeichnisstruktur balkanisiere
> möchte ich das nochmal zur Diskussion stellen.
1. $modpath/share/icons/weather
dein vorschlag. ich denke deine idee dabei ist: alles was anderen zur
gemeinsamen nutzung bereitgestellt werden soll, kommt nach $modpath/share. die
meinung teile ich im ersten schritt.
allerdings fällt mir im moment keine andere anwendung ausser im bereich der
webguis ein. daher würde ich folgendes vorschlagen:
2. $modpath/www/share/icons/weather
gruss martin
Dr. Boris Neubert
Am 19.05.2012 12:49, schrieb Martin Fischer:
> etc.). mein ziel ist, es noch dieses wochenende einzuchecken.
> 2. $modpath/www/share/icons/weather
Das ist für mich genauso in Ordnung. Ich melde dann auch gleich Bedarf
nach Doku an, über welche URL pgm2 dann die Icons serviert. Präziser:
was muß in
http://meinfhemserver:8083/MIRUNKLAR/weather/icon.png
für MIRUNKLAR stehen?
Viele Grüße
Boris
Martin Fischer
> Das ist für mich genauso in Ordnung. Ich melde dann auch gleich Bedarf
> nach Doku an, über welche URL pgm2 dann die Icons serviert. Präziser:
> was muß in
>
> http://meinfhemserver:8083/MIRUNKLAR/weather/icon.png
>
> für MIRUNKLAR stehen?
$MIRUNKLAR = "www/share/icons";
http://meinfhemserver:8083/$MIRUNKLAR/icon.png
für nicht shared icons:
$MIRUNKLAR = "www/weather";
http://meinfhemserver:8083/$MIRUNKLAR/icon.png
weiss aber eben nicht ob http://meinfhemserver:8083/ den pfad schon
unterstützt. ggf. muss das noch nachgearbeitet werden.
Jan-Hinrich Fessel
> Am Samstag, 19. Mai 2012, 15:10:09 schrieb Dr. Boris Neubert:
>> Das ist für mich genauso in Ordnung. Ich melde dann auch gleich Bedarf
>> nach Doku an, über welche URL pgm2 dann die Icons serviert. Präziser:
>> was muß in
>>
>> http://meinfhemserver:8083/MIRUNKLAR/weather/icon.png
>>
>> für MIRUNKLAR stehen?
>
> mein vorschlag für shared icons:
> $MIRUNKLAR = "www/share/icons";
> für nicht shared icons:
> $MIRUNKLAR = "www/weather";
> http://meinfhemserver:8083/$MIRUNKLAR/icon.png
Analog zu einem "richtigen" Web-server, der relativ zur HTTP-root adressiert.
Grüße
Oskar
Rudolf Koenig
Nein, das muss noch "nachgearbeitet" werden.
Bitte bedenkt, dass foldende Punkte auch beruecksichtigt werden muessen:
- FHEMWEB Instanz abhengige icons (noch nicht implementiert)
- style abhaengige icons (noch nicht implementiert)
- status wird auch angezeigt, indem man "icon/geraet" abfragt
Weiterhin hat jetzt pgm3 auch angefangen icons von pgm2 zu duplizieren, was mir
nicht passt. Wir sollten fuer fhem nur ein icon Verzeichnis haben, und das soll
nicht pgm2 spezifisch sein.
Dr. Boris Neubert
> Bitte bedenkt, dass foldende Punkte auch beruecksichtigt werden muessen:
> - FHEMWEB Instanz abhengige icons (noch nicht implementiert)
FHEMWEB-Instanz ist.
attr <NAME> FHEMWEB iconpath <ABSOLUTEICONPATH>
Default: ${modpath}/www/icons/
> - style abhaengige icons (noch nicht implementiert)
> - status wird auch angezeigt, indem man "icon/geraet" abfragt
Vorschlag:
http://hostname:8083/fhem/icons/<ICONNAME>
serviert die Datei <ABSOLUTEICONPATH>/<STYLE>/<ICONNAME>
Wenn es das Verzeichnis <ABSOLUTEICONPATH>/<STYLE>/ nicht gibt, wird aus
<ABSOLUTEICONPATH>/default/ serviert.
Viele Grüße
Boris
Rudolf Koenig
- www/icons
- www/<stylesheetPrefix>
- www/<FHEMWEB-instanzname>
Diese Verzeichnisse werden in dieser Reihenfolge nach Bilder gescannt, Instanz
hat also hoehere Prio als www/pgm2, usw.
Die Suche in www/pgm2 nach Bilder wird eingestellt, es gibt keine "pgm2"
spezifische Bilder, nur Instanz oder style spezifische, andere Frontends
sollten diese (soweit moeglich) mitverwenden.
Angesprochen via HTTP/FHEMWEB wird es (wie bisher) mit
http://fhemhost:8083/icons/iconname
Probleme:
- wie verschieben wir Dateien mit updatefhem. Generische Loesung bevorzugt:
ich will demnaechst XmlList/JsonList/updatefhem von 99 in 98 umbenennen, und
es nur bei Verwendung laden.
- das fb7390-er install muss angepasst werden.
- Eigentlich wuerde ich gerne die fuer den darkstyle gebauten icons in das
www/pgm2/dark Ordner verschieben, und so auszuliefern, habe aber Angst von
Meldungen wie "Meine Icons sind verschwunden", weil die damit beim
default-style nicht mehr sichtbar waeren.
- www entspricht im SVN webpgm. Das ist etwas ungluecklich, evtl. koennen wir
das eine dem anderen anpassen.
- Andere Baustellen (.gplot/style/.html) sind damit noch nicht erledigt.
Dr. Boris Neubert
Hallo,
Rudolf Koenig <inf...@koeniglich.de> schrieb:
>Vorschlag:
>- www/icons
>- www/<stylesheetPrefix>
>- www/<FHEMWEB-instanzname>
>
Ist obige Liste nach aufsteigender Prio geordnet?
Viele Grüße
Boris
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Rudolf Koenig
Da stimme ich Dir zu.
> Ist obige Liste nach aufsteigender Prio geordnet?
liest erst www/icons, dann www/<stylesheetPrefix>, dann iconpath, und
ueberschreibt evtl. vorhandene Eintraege. Damit werden beim gleichen Namen
Bilder aus iconpath und nicht aus www/icon genommen.
Dr. Boris Neubert
<FHEMWEB-instanzname> ist der Name im Define? Ich finde es besser, einem Attribut iconpath o.ä. die höchste Prio zu geben.
Da stimme ich Dir zu.Ist obige Liste nach aufsteigender Prio geordnet?FW_icons wird spaetestens nach 5 Sekunden durch FW_ReadIcons gefuellt. Dieser liest erst www/icons, dann www/<stylesheetPrefix>, dann iconpath, und ueberschreibt evtl. vorhandene Eintraege. Damit werden beim gleichen Namen Bilder aus iconpath und nicht aus www/icon genommen.
Quintessenz:
1. Ohne explizit auf ein altes oder neues Layout Bezug zu nehmen, werden alle Dateien nach wie vor richtig serviert, wenn es die separate $modpath/www-Struktur nicht gibt und alle Dateien in $modpath/FHEM herumliegen (Abwärtskompatibilität). => an meiner eigenen Installation getestet.
2. Das neue Datei-Layout ist an genau einer Stelle im Code definiert (FW_SetDirs). Ich hänge nicht an meinem Vorschlag (außer der Teil unter Icons, der muß so bleiben, damit es funktioniert).
3. Die erforderlichen Änderungen machen den Code griffiger/gekapselter.
Empfehlung:
M.E. sollte webfrontend/pgm2 aufgelöst werden: die Packages nach FHEM, die Icons, Stylesheets, GPlot-Dateien und Javascript-Includes nach www (siehe unten). Damit spart sich der Einsteiger das Herumkopieren der Dateien.
Offene Punkte:
1. Mir ist völlig unklar, wie das ganze mit fhemupdate housekeeping zusammenspielt. Die Standarddateistruktur im Tarball enthält kein www-Verzeichnis und die Icons liegen auch noch in webfrontend/pgm2. fhemupdate habe ich auf meiner Installation bisher nicht ausgeführt.
2. Ich gehe davon aus, daß FLOORPLAN angepaßt werden muß.
Anbei 01_FHEMWEB.pm zur Ansicht und zum Ausprobieren. Die Verzeichnisstruktur in www schicke ich Interessierten als gezippten Tarball per PM, da die Datei 1,3MB groß ist. Wenn FHEMWEB $modpath/www findet, werden einige Dinge erstmal noch nicht funktionieren. Das ist noch nicht fertig. Wie oben gesagt mache ich die Restarbeit, falls Ihr keinen Showstopper entdeckt.
Viele Grüße
Boris
Inner workings of the FHEMWEB server
The base URL of the FHEMWEB server is http://hostname:port/<webname>. The path <webname> is taken from the webname attribute of the FHEMWEB device. It defaults to "fhem".
The directory layout on the file system from which fhem serves files is either (new version)
$modpath/
www/
icons/
css/
javascript/
gplot/
docs/
or (old version)
$modpath/
FHEM
In the source code http://hostname:port/<webname> is in $FW_ME. The following global variables are used throughout fhem:
$FW_dir: base directory from which FHEMWEB serves files. The first existing directory from the following list is taken:
$modpath/www
$modpath/FHEM
$FW_icondir: base directory from which FHEMWEB serves icons. The first existing directory from the following list is taken:
$FW_dir/icons
$FW_dir [which is $modpath/FHEM in the old layout]
$FW_docdir: base directory from which FHEMWEB serves documentation. The first existing directory from the following list is taken:
$FW_dir/docs [usually does not exist]
$modpath/docs [this is where the documentation has ever been residing, no need to copy commandref.html & Co. anymore]
$FW_dir [which is $modpath/FHEM in the old layout]
$FW_cssdir: base directory from which FHEMWEB serves style sheets. The first existing directory from the following list is taken:
$FW_dir/css
$FW_dir [which is $modpath/FHEM in the old layout]
$FW_jsdir: base directory from which FHEMWEB serves javascript includes. The first existing directory from the following list is taken:
$FW_dir/javascript
$FW_dir [which is $modpath/FHEM in the old layout]
$FW_gplotdir: base directory from which FHEMWEB serves gplot files. The first existing directory from the following list is taken:
$FW_dir/gplot
$FW_dir [which is $modpath/FHEM in the old layout]
The following special URLs are recognized. This is all done from within FW_AnswerCall with the aid of FW_ServiceSpecial.
Icons
http://hostname:port/<webname>/icons/<icon>
This is the standard mechanism for retrieving a styled icon, both from within fhem and from the outside. Icon is just a name, without extension and without style prefix, e.g. "fhemicon".
The strategy for finding an icon is as follows (see FW_ReadIcons):
1. First collect all icons in the directory $FW_icondir/default.
2. If the stylesheetPrefix attribute is set, then collect all icons in the directory $FW_icondir/<stylesheetPrefix>.
3. If the iconpath attribute ist set, then collect all icons in the directory $FW_icondir/<iconpath>.
4. If no icons have been found so far, then collect all icons in the directory $FW_icondir.
Step #4 is required to find icons in the FHEM subdirectory $modpath/FHEM, where the icons used to reside in the old layout.
If a previously icon is found again in a later step, this icon is given preference over the previously found icon. For example, if <stylesheetPrefix> is "dark" and we have fhemicon both in $FW_icondir/default and in $FW_icondir/dark, the fhemicon from $FW_icondir/dark is taken.
The icon files can be in gif, jpg or png format. If two or three icon files for the same icon are available in the same directory, e.g. fhemicon.png and fhemicon.gif, png is preferred over jpg and jpg is preferred over gif.
<icon> can be a path. For example, weather/snow retrieves the file $FW_icondir/default/weather/snow.png. The ability to serve icons from subdirectories makes the existence of a "default" subdirectory for the default style a requirement. Serving icons from a subdirectory is not even tidier but also required to place third party collections together with a copyright notice in the structure as it is the case for Martin Preidel's weather icons.
Documentation
http://hostname:port/<webname>/docs/file
This is the standard mechanism to retrieve documentation, especially commandref.html: http://hostname:port/<webname>/docs/commandref.html.
html, txt and pdf files are recognized by their extensions. They are served from $FW_docdir (no subdirectories possible at this stage).
Style Sheets
http://hostname:port/<webname>/css/file
This is the standard mechanism to retrieve style sheets, e.g. default.css: http://hostname:port/<webname>/css/default.css.
They are served from $FW_cssdir (no subdirectories possible at this stage).
Javascript Includes
http://hostname:port/<webname>/js/file
This is the standard mechanism to retrieve style sheets, e.g. default.css: http://hostname:port/<webname>/js/svg.css.
They are served from $FW_jsdir (no subdirectories possible at this stage).
GPlot Files
http://hostname:port/<webname>/gplot/file
This is the standard mechanism to retrieve gplot files, e.g. temp4hum8.gplot: http://hostname:port/<webname>/gplot/temp4hum8.gplot.
They are served from $FW_gplotdir (no subdirectories possible at this stage).
Martin Fischer
> [...]
> either (new version)
>
> $modpath/
> www/
> icons/
> css/
> javascript/
> gplot/
> docs/
>
> or (old version)
>
> $modpath/
> FHEM
ausgelegt.
anmerkung1: warum nennt ihr das verzeichnis 'icons' und nicht 'images'? icons
erinnert so an windows-uralt und ausserdem könnte man dann ja auch die
floorplan images da hinein speichern. icons würde dann ja nicht ganz passen.
anmerkung2: was mir dabei nicht ganz gefällt ist, das www mit der obigen
struktur quasi von pgm2 eingenommen wird. wenn irgendwann mal ein weiteres gui
dazu kommt, wird zumindest das www/<stylesheetPrefix> in dieser struktur
verwirrend bzw. für das weitere gui ggf. komplett überflüssig sein.
ich würde daher eher im root von www tatsächlich nur die tatsächlich zu
sharenden objekte ablegen in der form von:
www/images
www/docs
und dann
www/<GUI-1>
www/<GUI-1>/css
www/<GUI-1>/javascript
www/<GUI-1>/gplot
...
www/<GUI-2>
www/<GUI-2>/css
www/<GUI-2>/javascript
www/<GUI-2>/images
...
<GUI-1> und <GUI-2> wollen vielleicht die shared icons aus www/images nutzen,
aber nutzen definitiv andere css und javascript dateien. <GUI-2> arbeitet
vielleicht garnicht mit gplot. darüber hinaus benutzt <GUI-2> noch weitere
images, die nur für die <GUI-2> zutreffen und in <GUI-1> keine verwendung
finden.
wird nun wieder alles unter z.b. www/css, www/javascript oder www/images
abgelegt, dann vermischen wir wieder dateien aus unterschiedlichen GUIs und
entwickler von anderen GUIs werden damit eingeschrängt, bzw. müssen sich bei
der namensgebung der z.b. javascripte, css datein, etc. gedanken machen, das
sie nicht so heissen wie die einer anderen GUI.
deshalb kopiert ja ein 'updatefhem housekeeping' auch nicht die pgm2 dateien
einfach nur in www sondern explizit nach www/pgm2. alles was ausschliesslich
zu pgm2 gehört sollte demnach auch _unter_ www/pgm2 landen. das was man ggf.
mit anderen guis teilen könnte / will, wie z.b. docs, faq und ggf. noch icons
/ images (fhem logo z.b.) sollten dann nach www/<ordner>
gruss martin
Martin Fischer
update und backup fertig haben will (obwohl es hier ja auch abhängigkeiten
gibt).
Am Mittwoch, 23. Mai 2012, 10:44:15 schrieb Rudolf Koenig:
> [...]
> spezifische Bilder, nur Instanz oder style spezifische, andere Frontends
> sollten diese (soweit moeglich) mitverwenden.
von myhce 2.0 ansiehst, dann wirst du feststellen, das meine "icons" (alle
selber gezeichnet) einen ganz anderen stil / grösse haben, wie die die bei
pgm2 angezeigt werden. auch würde ich die nicht ersetzen wollen.
3-4 nachrichten weiter im thread bin ich gerade auf boris' vorschlag bzgl. der
verzeichnisstruktur näher eingegangen, die meine bedenken etwas näher
erläutern.
> [...]
>
> - wie verschieben wir Dateien mit updatefhem. Generische Loesung bevorzugt:
> ich will demnaechst XmlList/JsonList/updatefhem von 99 in 98 umbenennen,
> und es nur bei Verwendung laden.
> [...]
> www/pgm2/dark Ordner verschieben, und so auszuliefern, habe aber Angst von
> Meldungen wie "Meine Icons sind verschwunden", weil die damit beim
> default-style nicht mehr sichtbar waeren.
zugänglich sein soll, müssen wir vielleicht _einmalig_ hinnehmen, das die
benutzer _einmalig_ selber hand anlegen müssen. nicht alles ist immer mit
einem vertretbaren aufwand zu automatisieren.
> - www entspricht im SVN webpgm. Das ist etwas ungluecklich, evtl. koennen
> wir das eine dem anderen anpassen.
sicht ein container für _mehrere_ GUIs werden, in dem jede GUI sein eigenen
pfad hat aber auch gewisse dateien, wie z.b. docs, etc. geshared werden.
> - Andere Baustellen (.gplot/style/.html) sind damit noch nicht erledigt.
grad faul um es zu verlinken ;-) )
Rudolf Koenig
- pgm5 stammt von pgm2 ab, und verwendet viele Dateien gemeinsam (deswegen der
Vorschlag von Boris). pgm3 und myHCE sind eigenstaendig, das erklaert Deine
Sicht
- Wiederverwendung von Dateien vs. komplette Installation eines separaten
Frontends in einem einzigen Verzeichnis(-baum).
Mein aktueller Vorschlag:
www/images
www/docs
www/gplot
www/pgm2
www/pgm2/dark
www/<GUI-x>
Images enthaelt alle z.Zt von pgm2 werwendeten Bilder, bis auf die icons, die
darkstyle spezifisch sind. Wie es unter www/<GUI-x> auschaut, wird dem
Frontend Author ueberlassen, ich werde fuer pgm2 Instanz und Style spezifische
Verzeichnisse zulassen.
Ich wuerde gerne "www/" im Pfad streichen. Widerstand?
Und ich wuerde die SVN Struktur bzw. Inhalt angleichen.
Martin Fischer
> [...]
> www/images
> www/docs
> www/gplot
> www/pgm2
> www/pgm2/dark
> www/<GUI-x>
> [...]
ich will nicht meine ganze argumentation wiederholen, denn sie steht ja in der
ersten nachricht dieses threads. um fhem eine saubere struktur mit auf den weg
zu geben, würde _ich_ das so machen:
> /usr/share/fhem
> /usr/share/fhem/contrib
> /usr/share/fhem/lib alternativ: /usr/share/fhem/modules
> /usr/share/fhem/locale/de_DE
> /usr/share/fhem/locale/en_EN
> /usr/share/fhem/www
> /usr/share/fhem/www/doc
> /usr/share/fhem/www/pgm2
und guis. ähnlich wie bei einem cms wo man ja auch inhalt von darstellung
trennt (vielleicht nicht ganz treffendes beispiel, geht aber in die richtung).
würdest du nun "www/" streichen, dann wäre zumindest aus meiner sicht $modpath
wieder auf dem weg des "durcheinanders" und der anwender weiss ggf. nicht auf
den ersten blick, was zu was gehört. kann er denn das verzeichnis gplot
löschen oder läuft dann fhem nicht mehr? liegt es aber in www, dann könnte man
da schon eher drauf schliessen, das es zu einer GUI gehört.
just my 2 cents.
> Und ich wuerde die SVN Struktur bzw. Inhalt angleichen.
müsste auch noch das makefile angepasst werden.
Dr. Boris Neubert
Am 01.06.2012 09:15, schrieb Rudolf Koenig:
>> ich würde daher eher im root von www tatsächlich nur die tatsächlich zu
> www/images
> www/docs
> www/gplot
> www/pgm2
> www/pgm2/dark
> www/<GUI-x>
$FW_dir: base directory from which FHEMWEB serves files.
The first existing directory from the following
list is taken:
$modpath/www
Statt www/images und www/pgm2/<stylesheetPrefix> finde ich
www/images/default
www/images/dark
etc. besser. Mit derselben Begründung, wie www/images eingerichtet wird,
nämlich, daß sich andere GUIs daraus bedienen können, würde ich die
Style-spezifischen Bilder auch allen GUIs zur Verfügung stellen.
Kompromißvorschlag:
www/
images/
default/
dark/
docs/ (NICHT ANLEGEN!)
gplot/
pgm2/
css/
javascript/
Ich hoffe, daß wir uns vor Sonntag einigen, damit ich darauf aufbauend
dann das 01_FHEMWEB.pm fertig machen kann.
> Und ich wuerde die SVN Struktur bzw. Inhalt angleichen.
Nochmal zu meinen Fragen:
- Die Verwender von updatefhem überleben diese Umstellung im SVN ohne
händische Eingriffe?
- Einsatz des überarbeiteten 01_FHEMWEB.pm erfordert Anpassungen an den
CSS, an den Namen der Icons (damit die Icons unter default und dark
gleich heißen), vermutlich an 95_FLOORPLAN.pm. Also muß gut getestet
werden und Uli die Möglichkeit zur Anpassung vom Floorplan gegeben
werden. Gibt es eine Möglichkeit, die Umstellung erst in einem
testing-Branch zu machen, bevor SVN-User reihenweise ausgeknockt werden?
Viele Grüße
Boris
Martin Fischer
> [...]
>
> - Die Verwender von updatefhem überleben diese Umstellung im SVN ohne
> händische Eingriffe?
"aufräumaktionen" abgegrenzt sind. siehe auch mein thread von heute
"funktionsumfang update / updatefhem" besonders der abschnitt mit der
filetimes.txt.
> - Einsatz des überarbeiteten 01_FHEMWEB.pm erfordert Anpassungen an den
> CSS, an den Namen der Icons (damit die Icons unter default und dark
> gleich heißen), vermutlich an 95_FLOORPLAN.pm. Also muß gut getestet
> werden und Uli die Möglichkeit zur Anpassung vom Floorplan gegeben
> werden. Gibt es eine Möglichkeit, die Umstellung erst in einem
> testing-Branch zu machen, bevor SVN-User reihenweise ausgeknockt werden?
lang gestöhne in fhem-users. ABER: nicht jeder individualfall kann dann
berücksichtigt werden. wie ich schon irgendwo schrieb: ausgangsbasis sollte
immer $modpath sein. wenn jemand sein system so verbiegt, das es komplett
abweicht, dann wird er wohl selber hand anlegen müssen.
gruß martin
Rudolf Koenig
> css/
> javascript/
Dann fehlt aber
pgm2/css/default
pgm2/css/dark
und das ist mir schon wieder zu kompliziert. Auf pgm2/css und pgm2/javascript
wuerde ich gerne verzichten, mir wuerde
pgm2/default
pgm2/dark
reichen. Und optional vom Anwender anlegbare pgm2/<fhem-instanzname>
> Gibt es eine M�glichkeit, die Umstellung erst in einem testing-Branch zu
anpassen, bzw. ein fhemupdate4 einrichten.
Dr. Boris Neubert
>> pgm2/
>> css/
>> javascript/
>
> Dann fehlt aber
> pgm2/css/default
> pgm2/css/dark
> und das ist mir schon wieder zu kompliziert. Auf pgm2/css und pgm2/javascript
> wuerde ich gerne verzichten, mir wuerde
> pgm2/default
> pgm2/dark
> reichen. Und optional vom Anwender anlegbare pgm2/<fhem-instanzname>
anlegen (wird m.E. derzeit auch nicht benötigt). Damit sind wir bei:
www/
images/
default/
dark/
docs/ (NICHT ANLEGEN!)
gplot/
pgm2/
> anpassen, bzw. ein fhemupdate4 einrichten.
Grüße
Boris
Rudolf Koenig
Branch ist trivial:
svn copy https://fhem.svn.sourceforge.net/svnroot/fhem/trunk/fhem\
https://fhem.svn.sourceforge.net/svnroot/fhem/branches/REORG/fhem
Move auch:
svn rename a b
Dr. Boris Neubert
Struktur. 01_FHEMWEB.pm muß ich noch weiter überarbeiten.
Welche Logik steckt hinter dem Angebot von Dateien zum Editieren (Edit
files)?
Konform wäre es, alles unterhalb von www/pgm2 sowie die
Konfigurationsdatei editierbar zu machen.
Für *mich* wäre es ideal, zusätzlich zu fhem.conf alle Dateien in
demselben und den darunterliegenden Verzeichnissen zum Editieren anzubieten.
Grüße
Boris
Rudolf Koenig
> files)?
.sh, .holiday, .ecmd (oder wie das heisst) Dateien, alle .cfg (auch die via
include), .css, .gplot usw.
> Konform w�re es, alles unterhalb von www/pgm2 sowie die
> Konfigurationsdatei editierbar zu machen.
Ist mir gleichzeitig zu viel (keine .pgm/.jpg) und zu wenig (siehe oben).
:)
Dr. Boris Neubert
im Zweig testing des SVN gibt es jetzt die erste Version der neuen
Verzeichnisstruktur, die für einen kleinen Kreis testbereit ist.
Die Struktur und die Verwendung im Code ist hier dokumentiert:
http://fhemwiki.de/wiki/DevelopmentDirectoryStructure
Ich habe es bei mir getestet. Getestet habe ich nicht die
Smallscreen-Geschichten.
webfront/pgm2 ist weg; die darin enthaltenen Dateien sind über www
verstreuselt bis auf 01_FHEMWEB.pm, welches nach FHEM gewandert ist.
Abwärtskompatibilität heißt, daß das neue FHEMWEB die Dateien aus FHEM
serviert, wenn die Ordner unter www (noch) nicht (alle) vorhanden sind.
Es wird aber nicht funktionieren, die Dateien aus www alle nach FHEM zu
kopieren, weil die Stylesheets in puncto
background-image:url(../icons/fhem.png); angepaßt wurden.
Am 03.06.2012 18:59, schrieb Rudolf Koenig:
>> Welche Logik steckt hinter dem Angebot von Dateien zum Editieren (Edit
>> files)?
>
> Alles, was der Benutzer selbst beim fhem veraendern "darf": eigene Util.pm,
> .sh, .holiday, .ecmd (oder wie das heisst) Dateien, alle .cfg (auch die via
> include), .css, .gplot usw.
müßten noch die Includes (am besten in fhem merken, welche das sind) und
die Benutzereinstellungen (layout, db.conf, *.classdef). Das kommt
irgendwann später
@Uli: Die Änderungen an FHEMWEB haben vermutlich FLOORPLAN
kaputtgemacht. Ich wage mich aber nicht daran, es zu ändern. Kannst Du
Dir bitte anschauen, ob Änderungen erforderlich sind? Ich helfe gerne
weiter (siehe Wiki-Eintrag oben zum Anfang).
@Martin, Rudi: würde sich updatefhem housekeeping um die Änderungen
kümmern?
Viele Grüße
Boris
Martin Fischer
> [...]
> kümmern?
etwas bremsen, da mir gerade andere sachen dazwischen hauen.
ich habe das eben nur kurz überflogen. wichtig für mich wäre dann z.b. bei
images default bzw. dark zu wissen, was zu was gehört.
muss ich mir halt erstmal in ruhe ansehen.
Dr. Boris Neubert
Am 17.06.2012 12:24, schrieb Martin Fischer:
> Am Sonntag, 10. Juni 2012, 18:20:24 schrieb Dr. Boris Neubert:
>> [...]
>> @Martin, Rudi: würde sich updatefhem housekeeping um die Änderungen
>> kümmern?
>
> images default bzw. dark zu wissen, was zu was gehört.
1. Erstelle www aus dem SVN mit allen Inhalten
2. Loesche webfrontend/pgm2
3. Verschiebe Dateien wie folgt:
FHEM/*.svg -> www/pgm2
FHEM/*.css -> www/pgm2
FHEM/*.js -> www/pgm2
FHEM/*.gplot -> www/gplot
FHEM/*.png -> www/images/default
FHEM/*.ico -> www/images/default
4. Update aus SVN auf fhem.pl und FHEM
Viele Grüße
Boris
Martin Fischer
Am Sonntag, 17. Juni 2012, 14:44:00 schrieb Dr. Boris Neubert:
> [...]
>
> 1. Erstelle www aus dem SVN mit allen Inhalten
> 2. Loesche webfrontend/pgm2
> 3. Verschiebe Dateien wie folgt:
> FHEM/*.svg -> www/pgm2
> FHEM/*.css -> www/pgm2
> FHEM/*.js -> www/pgm2
> FHEM/*.gplot -> www/gplot
> FHEM/*.png -> www/images/default
> FHEM/*.ico -> www/images/default
> 4. Update aus SVN auf fhem.pl und FHEM
http://groups.google.com/group/fhem-
developers/browse_thread/thread/b51af1e122cc9622/f0a42368468d9b8e?#f0a42368468d9b8e
dann würde ich mir die arbeit der migration sparen, bzw. nur am ende des
updates noch den move der verbleibenden dateien wie oben unter 3. angegeben
durchführen.
Dr. Boris Neubert
Am 17.06.2012 15:13, schrieb Martin Fischer:
> wollen wir nicht auch gleich die neue controls.txt dazu nutzen? siehe dazu
Viele Grüße
Boris