Frontend zum Eigengebrauch umgestalten

strauch · 17 Januar 2014, 16:29:37

Ich hatte mal was mit jquery mobile angefangen das war auch gut.

Gesendet von meinem Nexus 4 mit Tapatalk

molnitza · 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. 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.

strauch · 20 Januar 2014, 17:00:25

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

Johannes · 20 Januar 2014, 18:13:41

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 ...

reichi · 31 Januar 2014, 21:45:10

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?

rudolfkoenig · 31 Januar 2014, 22:30:20

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.

reichi · 31 Januar 2014, 23:34:21

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.

rudolfkoenig · 01 Februar 2014, 00:01:43

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.

reichi · 01 Februar 2014, 00:03:21

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.

reichi · 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.
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...

strauch · 02 Februar 2014, 12:19:12

Das wäre Klasse, bisher bin ich da auch zeitlich dran gescheitert.

Gesendet von meinem Nexus 4 mit Tapatalk

molnitza · 02 Februar 2014, 23:20:41

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?

reichi · 02 Februar 2014, 23:57:55

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

.

strauch · 03 Februar 2014, 10:25:07

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.

reichi · 03 Februar 2014, 11:41:07

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?