Hallo alle zusammen,
gibt es eine Möglichkeit mit der 99_myUtils.pm JavaScript und CSS in den Header oder/und Footer einzusetzen?
Oder gibt es generell eine Möglichkeit den Header oder Footer um eigene Scripte zu erweitern?
Gruß dort
Scripte einzufuegen kann man, indem man folgende Variable(n) setzt: $data{FWEXT}{meinscript}{SCRIPT} = "meinscript.js"
Eigenen CSS kann man mit einem neuen Style anfordern. Was mit header und footer gemeint ist, weiss ich nicht genau, vermutlich ist die Antwort nein.
Hi,
danke hat nach ein paar Versuchen wunderbar funktioniert.
Eigene Styles und JS in Header und Footer ->
Styles und JS in den <head> Bereich bzw vor dem </body> zu platzieren, wenn möglich noch in einer bestimmten Reihenfolge.
Andere Frage tut sich jetzt nach einigen Versuchen bei mir auf? Gibt es eine Möglichkeit das Rendering des darstellenden HTML zu beeinflussen ohne die 01_FHEMWEB.pm ändern zu müssen? Also Aufrufe der Ausgabe neu bzw umzuschreiben?
##############
# LOGO
my $hasMenuScroll;
if($FW_detail && $FW_ss) {
$FW_room = AttrVal($FW_detail, "room", undef);
$FW_room = $1 if($FW_room && $FW_room =~ m/^([^,]*),/);
$FW_room = "" if(!$FW_room);
FW_pO(FW_pHPlain("room=$FW_room",
"<div id=\"back\">" . FW_makeImage("back") . "</div>"));
FW_pO "<div id=\"menu\">$FW_detail details</div>";
return;
} else {
$hasMenuScroll = 1;
FW_pO '<div id="menuScrollArea">';
FW_pH "", '<div id="logo"></div>';
}
Gruß dorf
Das kann man doch mit JS hervorragend machen.
Hi,
klar kann man.
Dachte nur man könnte ein Framework über FHEM stülpen und somit erreichen das man nicht verschiedene Ports für die Frontends brauche und auch noch eine App. Dachte an Foundation, Bootstrap oder jQuery Mobile, somit wäre das Frontend responsive und auf allen Devices verfügbar.
Deswegen die Frage ob es eine Möglichkeit gibt das Rendering umzuschreiben ohne die 01_FHEMWEB.pm zu ändern.
Sowas wuerde ich an deine Stelle mit einem separaten index.html bauen, die JS und CSS laedt.
Die Daten kann man mit XmlList/JsonList holen, und auf Aenderungen mit inform reagieren.
Man koennte damit auch eine "offline" Anwendung machen, um Bilder nicht erneut zu laden.
Ok, schau ich mir mal an.
aber wie kann ich daten zurückschreiben?
Die andere Lösung wäre irgendwie eleganter gewesen, da das lediglich ein umschreiben des HTML bedeutet hätte.
Hi,
ich schon wieder. Hab mal einen Startscreen für Fhem in Bootstrap zusammen gestellt. Besteht für eine responsive Umsetzung des Frontend in einer der kommenden Versionen von Fhem evtl. die Möglichkeit?
Desktop
Mobile ab kleiner 768px
Zitat von: dorf am 04 November 2013, 23:48:02
Hab mal einen Startscreen für Fhem in Bootstrap zusammen gestellt. Besteht für eine responsive Umsetzung des Frontend in einer der kommenden Versionen
Das sieht ja richtig klasse aus! Ich habe für meine Zwecke die "brightstyle.css" etwas angepasst. Aber eine "responsive" Umsetzung wäre natürlich viel besser.
Ich hoffe das Projekt nimmt richtig Fahrt auf - viel Erfolg!
Update zu den ersten Screens. Eine Darstellung eines Room könnte dann so aussehen.
Sieht klasse aus!
Lass uns bitte an deinen Entwicklungsstand teilhaben ;)
Grüße
Hast du von deinem Frontend eine lauffähige Version die du uns zu Verfügung stellen magst?
Hi,
lauffähigen HTML Dummy hab ich zur Zeit nur. Eine Weiterentwicklung wurde leider aus beruflichen Gründen aufgeschoben, eng das ich im Februar / März weiter machen werde.
Das schaut sehr gut aus, hab auch angefangen ein anderes Design aufzubauen, mir fehlt aber auch etwas die Zeit. Machst du das ganze Responsive?
Er baut mit dem HTML Framework bootstrap, was genau für so etwas gedacht ist. Ich schaue mir FHEM das Wochenende mal an, da ich ein modernes Frontend programmieren möchte, in dem nur das nötigste angezeigt wird. Konfigurieren kann man schließlich auf dem originalen Frontend ausreichend gut. Vielleicht steht am Sonntag schon was brauchbares.
So wie es sich mir darstellt wird man die 01_FHEMWEB.pm direkt anfassen müssen. Sehe ich das richtig?
Ich hatte mal was mit jquery mobile angefangen das war auch gut.
Gesendet von meinem Nexus 4 mit Tapatalk
Ich bin zu dem Schluss gekommen, dass es am einfachsten wäre die fhemweb.pl dahingehend umzubauen, dass man die Ausgaben nicht direkt über die fhemweb.pl aufruft, sondern die Ausgaben in Variablen schreibt, die in einem separaten Template benutzt werden können. Dieses Template wird wiederum in der fhemweb.pl inkludiert. Ich habe bisher ein wenig "gespielt" und Teilfunktionen laufen auch schon, allerdings kann ich Perl nicht wirklich, aber großartig anders als C ist es nun auch nicht. Daher bin ich die ich recht zuversichtlich, dass ich demnächst was lauffähiges präsentieren kann.
Edit: Um das Rad nicht neu zu erfinden werde ich mich wahrscheinlich dem Perl Modul HTML::Template bedienen. Damit sollte sich alles relativ fix umsetzen lassen. Wenn ich soweit bin poste ich den Link zum Git Repo.
Ohja das wäre ganz großes Tennis. Damit könnte ich auch meine Oberfläche mit jquery mobile viel einfacher umsetzten. Danke ich bin sehr gespannt.
Gesendet von meinem Nexus 4 mit Tapatalk
Zitat von: molnitza am 19 Januar 2014, 23:52:38
Ich bin zu dem Schluss gekommen, dass es am einfachsten wäre die fhemweb.pl dahingehend umzubauen, dass man die Ausgaben nicht direkt über die fhemweb.pl aufruft, sondern die Ausgaben in Variablen schreibt, die in einem separaten Template benutzt werden können.
Was spricht den eigentlich gegen Rudis Ansatz, eigene index.html und Abfragen und Befehle über Ajax abzuschicken auf die bereits bestehenden Schnittstellen?
Damit müsste man das Rad nicht neu erfinden ...
Die Antwort ist sehr einfach.
Warum soll man denn jetzt den 5./6./7. Client neu implementieren?
Das ist leider kein Spass bei fhem, da man für jedes Protokoll spezifische Funktionen implementieren muss wenn man xmlllist oder jsonlist benutzen möchte. Die Interfaces sind ja noch nicht wirklich ausreichend implementiert.
Im Jahr 2014 spricht absolut GARNICHTS dafür in einer webapplikation mit hardcoded HTML zu arbeiten.
Es gibt doch sicher etablierte template engines für perl, warum also nicht FHEMWEB.pl auf templates umbauen und so die Möglichkeit für ein deutlich moderenes Web UI deutlich vereinfachen?!
Wenn sich schon jemand die Arbeit machen möchte würde massiv dazu raten FHEMWEB auf templating umzustellen. Dann können die Leute recht einfach neue oberflächen bauen egal ob mit bootstrap, jqueryui, sencha, extjs oder irgendeinem anderen framework OHNE jedesmal einen äußerst afwendigen javascript client bauen zu müssen (was wirklich unnötig ist).
Warum also ständig um die eigentliche richtige Lösung drum herum basteln, wenn man das ganze an der Wurzel packen und ordentlich lösen kann?
Mein Ansatz mit dem index.html ist, dass index.html nur dazu da ist, JavaScript Code zu laden. Bildschirm-Inhalt wird vom JavaScript Programm anhand der vom FHEM geholten JsonList zusammengebaut. Und ich habe auch nichts gegen Javascript-Bibliotheken, jquery+jquery-ui wird bereits per update ausgeliefert, da das Dashboard Modul es verwenden wollte.
Protokollspezifische Funktionen muss man mAn auch nicht implementieren, FHEMWEB macht es auch nicht. Und FHEMWEB wird nicht auf irgendwelche Template-Bibliotheken umgestellt, wuerde bei den o.g. Ansatz auch nichts bringen.
Das sehe ich anders ;)
Warum diese absolute Ablehnung im Bezug auf eine Template Engine?
Es hat quasi nur Vorteile und die Performance für das bisschen HTML das FHEM so erzeugt wird imo auch mit einer template-engine nicht erwähnenswert schlechter werden.
FHEM leidet meiner Meinung nach sehr darunter keine aufgeräumte, intuitive, moderne Web-Oberfläche zu haben.
Außerdem möchte ich gar kein jqueryui sondern Bootstrap, bin ich jetzt doof und darf nicht? ;).
Mit Templates wäre egal welche "Boilerplate" man für das HTML Frontend benutzen möchte. Es würde sich auch die Möglichkeit eröffnen völlig unterschiedliche aussehende WebFrontends auf unterschiedlichen Grundlagen zu bauen ohne dafür eine Zeile JS schreiben zu müssen.
Und warum soll man jetzt nochmal einen javascript-client für jsonlist/xmllist bauen, der noch dazu jedesmal mindestens 2 anfragen pro device benötigrt um überhaupt zu wissen was er da vor sich, hat (da die interfaces nur über jsonlist <DEVICE> in Erfahrung zu bringen sind. andFHEM ist ein prima Beispiel für die Probleme die man bekommt wenn man ein hübsches in intuitives Frontend für fhem bauen möchte.
Und ja, man KANN jsonlist benutzen und damit ein reines "AJAX"-basiertes frontend bauen. Aber das spricht doch nicht dagegen FHEM selbst mal standardmäßig mit was modernem auszustatten?
Und wenn man den hmtl-code in FHEMWEB schon mal anfasst dann sollte man IMO direkt alles in templates packen. Die kann man in den meisten engines precomiplen, wodurch sie nativem perl-code entsprechen was die Performance angeht.
Wieso nicht mal die Option eröffnen dass in sachen HTML geübte leute coole versionen des Frontends bauen können ohne auch nur eine Zeile javascript schreiben zu müssen?
Die Tatsache dass es mittlerweile 4 oder 5?! Web-Frontends gibt zeigt doch, dass man da wirklich einiges verbessern könnte und warum nicht endlich an der Quelle damit anfangen?
Aus objektiver Sicht spricht in meinen Augen absolut alles dafür sich von hardcoded HTML in FHEMWEB zu verabschieden.
Zum Thema Protkollspezifisch:
Wenn man komfortabel einen weekPlan z.B. für MAX! Thermostate setzen möchte muss ein Client das aktuell protokollspezifisch implementieren. Ein "set" befehl hat überhaupt nichts mit einem WebFrontend zu tun, das ist ja nur eine simulierte Commandline...
Nur damit hier kein falscher Eindruck entsteht.
FHEM hat einen beeindruckenden Funktionsumfang, aber ist in vielen Fällen für Personen ohne Entwicklungserfahrung (und perl Kenntnisse) aktuell eine gigantische Herausforderung.
Ich denke man könnte da mit einem guten WebFrontend sehr viel zur Vereinfachung beitragen.
Mir ist klar, dass das viel Arbeit ist und man das nicht "mal eben" macht aber man muss immer irgendwann anfangen :).
Ich bin zwar hauptberuflich Entwickler allerdings habe ich perl bisher erfolgreich umschifft (ich bin eher der c++, java, python, js typ) jetzt da ich hier FHEM einsetze hätte ich allerdings durchaus lust in sachen Browserbedienbarkeit meinen Beitrag zu leisten.
Es gibt kein "FHEM selbst". FHEMWEB ist ein Modul, und ist in keiner Weise ausgezeichnet. Steht dir, wie jedem sonst, frei was besseres mit Perl (oder was anderes) und Templates zu implementieren.
Nur bitte nicht versuchen mich zu irgendwelchen Umbauarbeiten zu noetigen, ich weiss schon selbst, was ich gerne machen moechte.
Ich habe nie gesagt "Du sollst das machen". Ich habe das genaue Gegenteil davon gemeint :).
Vielleicht habe ja auch ich tats. die Zeit und Lust das mal anzugehen.
Ich habe heute Vormittag mal etwas mit xslate (http://xslate.org/) experimentiert und das sah für's Erste eigentlich recht vielversprechend aus.
Ich denke ich versuche mal FHEMWEB.pl entsprechend umzubauzen, wie man das Modul dann später tats. nennt sei erst mal dahingestellt.
Wenn erst mal alles in Templates umgepackt ist sollte es ziemlich einfach möglich sein etwas modernes auf Basis von Bz.B. ootstrap oder jqueryui/jquerymobile, sencha, etc zu bauen.
Mal sehen was meine Zeit erlaubt die nächsten Wochen...
Das wäre Klasse, bisher bin ich da auch zeitlich dran gescheitert.
Gesendet von meinem Nexus 4 mit Tapatalk
Zitat von: reichi am 02 Februar 2014, 00:34:56
Ich habe heute Vormittag mal etwas mit xslate (http://xslate.org/) experimentiert und das sah für's Erste eigentlich recht vielversprechend aus.
Ich denke ich versuche mal FHEMWEB.pl entsprechend umzubauzen, wie man das Modul dann später tats. nennt sei erst mal dahingestellt.
Für den Ansatz mit der FHEMWEB.pl spricht natürlich, dass Änderungen die in dieser aufgrund diverser Modulkompatiblitäten vorgenommen werden, sich ohne Mühe enpflegen lassen. Ich bin grad dabei mich erstmal kundig zu machen welche verschiedenen Template Engines es überhaupt gibt. Ich häbe zwar bisher schon html::template (eher rudimentär) eingebaut, allerdings bin ich noch alles andere als zufrieden damit, zumal es im Template so einfach wie möglich sein sollte Inhalte einzusetzen ohne wiederrum mit irgendwelchen loops arbeiten zu müssen. Die andere Frage die sich mir stellt ist wie flexibel man den sein möchte. Hast du dir dazu schon Gedanken gemacht?
Ich weiß, dass loops in templates den Nachteil haben dass die templates komplexer werden ABER - Sie bieten einen nicht zu unterschätzenden Vorteil!
Man ist im Template nicht mehr ganz so stark darauf angwiesen irgendwelchen "vorgedachten" Strukturen zu folgen.
Erfahrungsgemäß führt genau das immer wieder dazu dass man zwar templates hat aber stellenweise irgendwie doch nicht "so richtig frei templaten" kann.
Was potentiell natürlich noch problematisch werden kann ist, dass sich z.B. jquery-ui und bootstrap (wenn man ein bootstrap basiertes ui baut, was ich mir wünschen würde) nicht uneingeschränkt vertragen. Und gerade z.B. das Dashboard benutzt afaik jQuery UI. Das sind allerdings letztlich eher "sekudäre" Probleme die man aktuell nicht lösen muss...
Ich bin wie gesagt totaler Perl Anfänger, habe aber durchaus Erfahrung im Bereich von WebInterfaces (als einer der einer der primären "Erschaffer" und Maintainer des Dreambox WebInterfaces), sowohl im Bereich von Web-Frontends als auch im Bereich des Backends (dazu sei gesagt, dass das Dreambox WebInterface mein erstes Projekt in dieser Richtugn war und ich heute vieles anders machen würde).
Und langsam aber sicher gewöhne ich mich auch an die Perl Syntax...
Momentan versuche ich FHEMWEB von HTML zu befreien und sämtliche Daten in entsprechenden Arrays/Hashes vorzuhalten. Das sollte unabhängig von der Template-Engine für die man sich letztlich entscheided ohnehin zwingend nötig sein.
XSlate war meine Wahl weil es z.B. in DuckDuckGo eingesetzt wird und sich aktiv in Entwicklung befindet.
Außerdem fand ich den Funktionsumfang sehr überzeugend.
Aus meiner Sicht ist xslate mit Kolon als Syntax deutlich moderner, intuitiver und reduzierter im Overhead wie html::template (dessen Syntax ich pers. grausam "lang" finde).
Wenn du tats. auch lust hast aktiv an der Sache mitzuwirken sollten wir vielleicht versuchen nicht nebeneinander her zu entwickeln.
Die notwendigen Umbauten sind ja erst einmal nur (teils mühsame) Fleißarbeit die ich mir gerne mit jemandem teile ;).
IMO sollte man als erstes FHEMWEB wie es jetzt ist vollständig auf templates umstellen.
Ich denke erst wenn das vernünftig läuft macht es Sinn z.B. ein Bootstrap oder jquery-ui basiertes Template aufzubauen. Welches Template später letztlich laufen soll kann man dann ja recht einfach über ein passendes attr steuern.
Die Andere Möglichkeit wäre natürlich die, die der Chef (also rudolfkoenig) persönlich vorgeschlagen hat, die natürlich auch für FHEMWEB machbar wäre:
Ein vollständiger Umbau auf ein "Web 2.0 AJAX" Web Interface, auf Basis von jsonlist, welches die Templates auf Client-Seite verarbeitet (die Dreambox macht das z.B. so).
Soweit ich das bisher abschätzen kann wäre das aber ein ganzes Stück mehr Arbeit! Wohl so viel mehr, dass ich jetzt schon sicher bin, dass mir dafür die Zeit fehlt. Außerdem bin ich mittlerweile nicht mehr so der Fan von client-side templates...
Zuletzt sei noch gesagt, dass egal was man nun eigtl baut, man es ja ohnehin als eigenes Modul anbieten kann. FHEMWEB wie es jetzt ist ist lediglich die Basis auf der man starten kann :).
Zitat von: reichi am 02 Februar 2014, 23:57:55
Die notwendigen Umbauten sind ja erst einmal nur (teils mühsame) Fleißarbeit die ich mir gerne mit jemandem teile ;).
IMO sollte man als erstes FHEMWEB wie es jetzt ist vollständig auf templates umstellen.
Ich denke erst wenn das vernünftig läuft macht es Sinn z.B. ein Bootstrap oder jquery-ui basiertes Template aufzubauen. Welches Template später letztlich laufen soll kann man dann ja recht einfach über ein passendes attr steuern.
Ich teile auch gerne, ich helfe gerne auch bei stumpfer Fleißarbeit. Mein Perl ist zwar auch mächtig eingerostet, aber ich hätte auch gerne ein themebares Webfrontent (ich hab irgendwann mal das hier in jquery gebastelt, aber ohne Funktion: http://fhem.webmanufactur.net )
Mir fehlt aktuell aus familiären Gründen einfach die Zeit mich tief in was reinzudenken, aber wenn du Fleißarbeit hast, das sollte ich hinbekommen.
Wenn ich mir den Aufwand so ansehe das aktuelle HTML zu portieren sollte man vielleicht doch überlegen direkt was neues zu bauen... Aber eigentlich halte ich das nicht für die richtige Heransgehensweise.
Wenn man einfach doch ein definitiv "neues und zusätzliches" web-modul daraus macht wäre das eigtl kein Thema.
Die FHEM-Web von html zu befreien ist an sich bei weitem nicht so aufwändig wie die umstrukturierung des existierenden htmls in templates.
Wie sieht der Rest das so?
@reichi: wie wärs mit einem kleinen Brainstorming. So ließen sich recht schnell Ideen und Probleme im Vorfeld finden.
wie wärs mit dem irc channel?
OK. Ich bin ab sofort im Normalfall "immer" im Channel (bzw ist mein Bouncer das). Also einfach mal vorbeiguggen ;).
Ich habe gestern Abend mal etwas mit Bootstrap gespielt und mir mal ein kelines template für die Raumansicht gebaut.
https://home.reichholf.net/boot/
Ich persönliche finde die "Widget"-Ansicht ja schöner als eine tabellarische Ansicht. Des Weiteren passt diese sich besser an kleine Bildschirme an :).
Den Plan das aktuelle FHEMWEB html-technisch zu migrieren habe ich langsam aber sicher über Board geworfen.
Die Zeit man benötigen wird um das aktuelel HTML zu portieren wird vmtl. genau so viel sein (eher noch mehr) wie für ein völig neues (moderneres) Layout.
Da FHEMWEB ja funktioniert und man einfach ein neues Modul nehmen kann würde ich tats. vorschlagen man FHEMWEB als basis für die benötigten Daten zu nehmen, das HTML einfach zu entfernen und dann mit eigenen templates was neues zu bauen.
Ich hoffe mal in spätestens 3 Wochen einen Prototypen zu haben mit dem die Rooms "nutzbar" sind (also Räume wechseln und einstellungen in den Räumen tätigen).
So in der Art würde auch mein Template aussehen. Leider werde ich vorm Wochenende keine Zeit finde mich weiter mit dem Projekt zu beschäftigen (60 Stunden Woche).
@Reichi das gefällt mir schon sehr gut, auch das es responsive ist. Das wäre von der UI her schon ein großer Schritt für FHEM.
Bootstrap eben ;).
Ich hab gestern Abend einen sehr sehr rudimentären prototypen gebaut, der immerhin schon mal Raumnavigation inkl. aller Geräte im Raum + Status "real" anzeigt (die basis sind alte logfiles auf einer zusätzll fhem installation aber das ist ja egal).
Aber bevor man das irgendwem geben kann sind noch einige Herausforderungen zu bewältigen ;).
Machst du die SVG Grafiken ebenfalls responsive? Gibt dazu ja auch einige techniken wäre ja für die ganzen Diagramme praktisch.
Du meinst die Plots?
Ich denke erst einmal gibt es noch andere Aufgaben. Letztlich müsste ich dazu die komplette SVG.pm auch noch umschreiben. Erst einmal möchte ich das aber mit der FHEMWEB hinkriegen... und da ist noch mehr als genug zu tun.
Ähh ich mein die Plots ja. Aber da hast du recht ist noch mal eine andere Baustelle. Wenn du was zum testen hast, dann schreib bescheid :-)
Ich habe mal meinen Versuchs-Prototypen auf github vernöffentlicht.
Er kann Raumnavigation und Device-Status anzeigen (beachtet aber keinerlei gerätespezifisches html wie z.B. bei SVG, etc).
Ich bitte darum den Spass nicht auf irgendwelchen produktiven installationen zu testen. Wenn man an die falsche stelle klickt (Floorplan z.B.) stürzt fhem unvermittelt einfach ab.
https://github.com/sreichholf/fhem-webapp
Nochmal die deutliche Warnung:
- Es ist ein PROTOTYP (pre-alpha) den kein normaler User auch nur ansatzweise testen möchte
- Es tötet FHEM in einigen fällen völlig unvermittelt
- Es ist nur für Leute gedacht die vielleicht mithelfen wollen
- Es kann nichts außer ein bisschen was anzeigen
- Es benötigt Text::Xslate
Wenn jemand wissen möchte wie sich das perl-seitig unterscheidet, dann kann einfach nach "$FWA_xslate" suchen. Dort werden die templates gerendert.
Ich werde mich mal dran machen wenn ich zu Hause bin.
FWA_pO sollte aus Kompatibilitätsgründen wie ursprünglich in FW_pO umbenannt werden. So spart man sich mühevolles Umschreiben anderer Module.
das wird aber nicht mehr so funktionieren wie früher... bzw... ich weiß nicht ob man das wirklich will :/. Ich kann das aber auch nicht abschätzen...
Die Frage ist ja erstmal was man wirklich will. Entweder man möchte ein paralleles System aufbauen oder aber man versucht die Kompatibilität zu anderen Modulen zu wahren. Ich denke letztere Möglichkeit dürfte zielführender sein, da etliche Module mit den subs von FHEMWEB arbeiten.
die schreiben direkt in den FD, das ist mit templates praktisch unvereinbar...
Genau DAS ist das größte aller Probleme.
Wenn wieder jeder direkt html in den Filedescriptor schreibt kann man das ganze auch direkt wieder lassen...
Ich hab nicht den vollständigen überblick. Aber ich sehe das SEHR kritisch wenn irgendwer von extern direkt in den FD schreibt.
Ich hab mir nochmal Gedanken gemacht.
Im Wesentlichen gibt es da mehrere Probleme...
1. Doppelte definition der selben Funktion, FW_pO ist ja bereits in 01_FHEMWEB.pm definiert, man wird also auf jedenfall irgendwas "zaubern müssen
2. Grundsätzlich kann man das Ding auch in Verbindung mit templates nutzen. soweit ich das gesehen habe nutzen die externen Funktionen ja webCmds. D.h. man kann die FWA_pO so gestalten das externe plugins uns ihren html code geben und wir diesen dann dem template übergeben (mark_raw wird ja auch so schon an einigen stellen benutzt).
vom Prinzip her:
Webcommand -> FW_pO -> tempvar -> template hash/array
Ich denke das erste Ziel sollte aber sein die Standardfunktionen der FHEMWEB neu abzubilden. Die Problematik mit den webcommands und der FW_pO muss man dann nochmal getrennt betrachten. Es im Kopf zu haben und sich nicht direkt alles verbauen ist aber sicher sinnvoll.
Da möchte ich mal nach Fragen, wie das ganze denn jetzt aussieht?
Ich habe mir mal die Oberfläche angesehen und momentan wird das ganze ja in Tabellenlayouts gelöst, was ist da für die Zukunft angedacht?
Persönlich würde es mir gefallen wenn man wie bei einem CMS ein Frontend und ein Backend (wurde hier schonmal geschrieben) hat. Im Backend also alle Einstellungen tätigen und im Frontend wird die Möglichkeit der Übersicht (Floorplan/Dashboard) gegeben und die einzelnen Räume zum ansteuern. Leider habe ich noch nie mit Perl gearbeitet, weiß also nicht wie die Ausgabe bisher geregelt wird, aber vielleicht könnte man ja für die Version 5.6 andenken, dass man die Ausgabe grundsätzlich mit php realisiert, also einen Header-Bereich, linke Spalte, Content, Footer.
Gruß
Zitat von: fkhm am 10 Februar 2014, 11:59:22
Leider habe ich noch nie mit Perl gearbeitet, weiß also nicht wie die Ausgabe bisher geregelt wird, aber vielleicht könnte man ja für die Version 5.6 andenken, dass man die Ausgabe grundsätzlich mit php realisiert, also einen Header-Bereich, linke Spalte, Content, Footer.
Ob du das mit php oder perl machst ist egal. Ein Umstieg von php auf perl nur für das Webfrontend ist nicht notwendig.
Bisher ist auch nicht geplant ein Backend oder Frontend zu machen, sondern überhaupt die "Webausgabe" von FHEM auf ein anderes System umzustellen, so das es sich leichter umgestalten lässt. Ganz unabhängig davon was damit dargestellt wird.
Ein Backend oder Frontend wäre eine ganz andere Baustelle und auch unabhängig davon. Und benötigt vielleicht auch noch ganz andere Baustellen.
Ich habe gestern Abend mal wieder ein bisschen gebastelt.
Man kann jetzt immerhin Dateien bearbeiten (und natürlich auch die liste Anzeigen).
Außerdem gibt's werden fehler beim Rendern von templates nun eingefangen und im Browser ausgegeben.
Da mir bei Perl nach wie vor etwas die Übung fehlt geht das alles leider nicht so schnell wie ich das gerne hätte ;).
Bzgl Plots und Co. bin ich aktuell noch nicht sicher wie ich das am Ende angehen soll, aber irgendwas wird mir da sicher einfallen.
Im Vordergrund steht für mich momentan aber eine gewisse Grundfunktionalität bereitzustellen.
Grundfunktionalität ist aus meiner sicht vor allem eines:
-> Aktoren schalten und ihren aktuellen Status anzeigen (Schalter, Dimmer, Thermostate, Jalousien)
"Luxusfeatures" wie Plots & Co. kann man sich dann später ansehen :).
Die Änderungen sind im git, Anmerkungen, Anregungen und Kritik sind jederzeit willkommen.
Hier nochmal der Link zum git: https://github.com/sreichholf/fhem-webapp
Toll zu sehen das du da dran bist ich schau mal ob ich am we eine test Installation mache um das anzuschauen
Gesendet von meinem Nexus 4 mit Tapatalk
Bei der wirst du dann sogar SVGs sehen können ;).
Ich habs eben so weit hinbekommen... denke ich... irgendwie ists ein hack, aber hey... es funktioniert ohne "alles kaputt" zu machen. So gesehen kann ich das ganz gut vertreten :).
Hi Reichi,
dh FHEMWEBAPP und FHEMWEB können nun in friedlicher Koexistenz laufen?
Wie komme ich dann aufs interface von FHEMWEBAPP?
Werde am WE mal versuchen Text::Xslate auf die fritzbox zu bringen und deine WEBAPP testen ;)
lg HolyMoly
man kann über webapp aber nichts einstellen gell ;). Und es kann nach wie vor zu harten abstürzen von FHEM kommen (bis wir die Phase verlassen haben wird ncoh etwas Zeit vergehen).
Man konfiguriert sie einfach auf nem anderen port über das übliche define (mit FHEMWEBAPP statt FHEMWEB).
Wie gesagt kann derzeit aber nur Entwicklungsinteressierten dazu raten.
Und wovon ich absolut abrate ist es das ding auf einer produktiven fhem instanz zu installlieren (hier läuft fhem derzeit noch auf der Fritz, wird aber auf den PI umziehen auf dem ich grad entwickle).
Nachtrag:
Ich hab mal nen screenshot gemacht: https://reichholf.net/cloud/public.php?service=files&t=b132ad5d96d2015a619eef7260caf46a
Die Graphen sind leer weil die logs veraltet sind!
Ich bin recht neu hier und lese mich gerade erst in die Thematik ein.
Sobald ich die eigentliche Installation von FHEM bei mir gemacht habe, werde ich mir das GIT Repo mal reinziehen. Ich kann absolut kein Perl (eher JS, PHP, C#) von daher bin ich gespannt wie das ausgeht ;-)
Wie sieht es mit Fortschritt aus? Die letzten Commits im GIT Repo sind ja ne Weile her (no offense). Allerdings habe ich das deutliche Gefühl, dass das "the way2go" ist. Du machst hier super Arbeit Reichi und ich hoffe du findest die Zeit da kontinuierlich weiterzuentwickeln!
Das ist ein TOP Projekt und für viele Leute, die sich für ein Hausautomations-System entscheiden müssen, ist ein ansprechendes UI ein ENTSCHEIDENDES Kriterium. Im Sinne der Verbreitung (und dementsprechend der Langlebigkeit) von FHEM wird das immer wichtiger!
Ich will nicht wissen, wieviele Leute auf Loxone oder IPS nur wegen der schön anzusehenden UI setzen (und das obwohl so ein Miniserver evtl. nicht mal notwendig wäre...)
Hi,
bei mir ist das immer so ne "schubweise" sache. D.h. ich werde immer wieder mal spontan 1-2 tage richtig was machen und dann liegts wieder ne Zeit.
Und als Info: ich hab vorher noch nie auch nur eine Zeile Perl geschrieben (allerdings sind mir diverse andere Sprachen durchaus geläufig).
Ich beteilige mich mal an dieser Stelle. Der Ansatz, das FHEMWEB Template-basiert zu gestalten gefällt mir sehr gut.
Mein Fork findet sich hier: https://github.com/dsgrafiniert/fhem-webapp
Hi @all,
hat sich hier eigentlich noch irgendwas getan in Sachen Bootstrap etc?
Es ist sehr lange hier schon ruhig :-[
Würde mich freuen wenn man da noch wieder was zu hört