[FHEM Tablet-UI] Dokumentation (Diskussionsthread)

[Ulm32b]

Hallo,
ich möchte die Sache mit den CSS-Klasse noch einmal hochkochen. Bislang gibt es keinen Vorschlag, wie wir das effizient auf die Reihe bekommen. Wie wäre es mit folgendem Ansatz:
Jemand ( ) erstellt eine FTUI-Seite und unterteilt diese schachbrettartig. In die einzelnen Felder kommt:

<div data-type="xxx" class=""></div>
<div data-type="label" class="inline">xxx</div><div data-type="label" class="">Referenz</div>

<div data-type="xxx" class="mini"></div>
<div data-type="label" class="inline">xxx</div><div data-type="label" class="inline">mini</div>

<div data-type="xxx" class="big"></div>
<div data-type="label" class="inline">xxx</div><div data-type="label" class="inline">big</div>

usw. (Vereinigungsmenge aller bekannten Klassen)

In einem Text-Editor ersetzt man nun xxx durch das zu untersuchende Widget (suchen -- ersetzen). Anschließend schaut man sich die in FTUI erzeugte Oberfläche an. Überall dort, wo sich das Bild nicht von der Referenz unterscheidet, hat die CSS-Klasse (augenscheinlich) keine Wirkung.
Das Verfahren muss wahrscheinlich noch verfeinert werden, damit man z.B. die Positionierung gegenüber benachbarten Widgets beurteilen kann.

Auf diese Weise könnte jemand () die von mir erträumte große Tabelle Widgets vs. CSS erstellen. Die wäre für sich schon ein großer Wurf. Ich würde mich nicht wundern, wenn da Überraschendes zu Tage träte. Im letzten Schritt würden die Ergebnisse in die einzelnen Widgetbeschreibungen übertragen werden.

Was haltet ihr davon?

[drhirn]

Kann jemand gerne machen .
Voraussetzung ist, dass wir alle Klassen zusammengesammelt haben. Sonst muss jemand dass für alle Widgets jedes Mal wiederholen, wenn eine neue Klasse auftaucht.

Und bei Sachen wie "hide-on" muss dann natürlich immer ein Reading dafür erstellt werden. Und bei Switches müsste jemand auch auf jeden draufdrücken. Usw usf

[setstate]

CSS kann man aber nicht nur zur optische Veränderung benutzen. Im JavaScript kann man auf Vorhandensein bestimmter Klassen prüfen und dann erst zur Laufzeit Aktionen ableiten.
Zum Beispiel "timestamp" bei Label hat keine Style Auswirkung, es wird aber dadurch etwas anderes angezeigt.
Offizielle Empfehlungen sagen zwar, solche Script beeinflussenden Klassen sollen auch besonders gekennzeichnet werden, mir Vorsilben zum Beispiel. js-timestamp müsse das stattdessen dann heißen. Aber ich kann mich damit noch nicht recht anfreunden, obwohl wir genau diese Unterscheidung jetzt bräuchten.

[Ulm32b]

Code Auswählen Erweitern

CSS kann man aber nicht nur zur optische Veränderung benutzen. Im JavaScript kann man auf Vorhandensein bestimmter Klassen prüfen und dann erst zur Laufzeit Aktionen ableiten.

o.k.
Die optisch unveränderten CSS wären dann "Kandidaten", bei denen man noch genauer hinschauen müsste. Kann jemand schätzen, wie groß der Anteil solcher Fälle wäre? Gefühlsmäßig eher überschaubar. Wir wollen ja nicht zum Mond fliegen und brauchen nur eine 80%-Lösung.

[drhirn]

Wir wollen ja nicht zum Mond fliegen und brauchen nur eine 80%-Lösung.

Hmm, dann können wir's aber gleich so lassen, wie's ist

[Ulm32b]

Mit 80%-Lösung meinte ich, dass wir "automatisiert" 80% erledigen und vielleicht damit 80% (auch 50% wäre schon super) des Aufwandes einsparen, am Ende aber eine zu 99% korrekte Doku haben.

Wenn ich mir die bisher erstellten Dokus so anschaue, sind die angegebenen CSS-Klassen wohl nicht überprüft und insbesondere auch keine fehlenden ergänzt worden. Bei meinen ersten Widgets habe ich die Überprüfung der Funktion noch durchgeführt, es dann aber auch bleiben lassen. Müssten wir nicht derzeit bei den CSS-Klassen "SIND UNGEPRÜFT" vermerken?

Das ganze Thema könnte auch zu einem späteren Zeitpunkt noch einmal angegangen werden. Vielleicht hat bis dahin jemand noch eine bessere Idee. Nur her damit.

[drhirn]

Aso, so meinst du das.

Also ich teste die Klassen immer durch. Will ja wissen, was ich da dokumentiere. Und schau in den Quellcode des jeweiligen Widgets, ob ich noch was finde. Lernt man viel dabei .

Ich hätte aber auch gesagt, kümmern wir uns später drum. Nützen wir jetzt lieber noch den nachlassenden Anfangsschwung und schauen, dass wir die Inhalte mal vollständig ins Wiki bringen.

[Standarduser]

Ich hätte aber auch gesagt, kümmern wir uns später drum. Nützen wir jetzt lieber noch den nachlassenden Anfangsschwung und schauen, dass wir die Inhalte mal vollständig ins Wiki bringen.

Dieser Meinung würde ich mich anschließen. Wenn ich mir überlege, wieviel Zeit ich schon in das Chart investiert habe und was das Ergebnis davon ist, hab ich da im Moment einfach überhaupt keine Lust drauf. Meist sitze ich an meinen Blog-Beiträgen nicht so lange, und da steckt teils deutlich mehr dahinter und auch das Ergebnis ist viel anschaulicher.

Aber ich will Dich keinesfalls bremsen und würde Dich auch dabei unterstützen, aber alles durchzutesten ist mir im Moment zu viel Arbeit. Ihr müsstet mal meine UI sehen, da würde ich das große Lachen kommen. Oder das Heulen 

[drhirn]

Schmeiß eine "Todo"-Vorlage ins Chart-Widget und mach zwischendurch was einfaches. Zwecks Motivationsgewinnung. Simplechart z.B.

Und bevor ich's vergesse, ich bin grad am Knob-Widget dran.

[Standarduser]

Nee, ich hab ja auch ein kleines Ziel vor Augen:
Im Moment funktioniert das Meteogram nicht - zeigt nix mehr an. Und so richtig gut gefallen hat mir das auch nie.
Ich möchte sowas ähnliches mal mit dem Chartwidget bauen. Da kann man neben fa-icons auch verlinkte Icons anzeigen. Hab nur noch keinen Plan, wie das richtig funktioniert.

[Ulm32b]

class="nocache" bei image mit rein und die url ohne das?_=1234567

o.k.
Ich kann nach ausgiebigem Test bestätigen, dass die Umgehung des Browser-Cache ("nocache")

funktioniert mit:
<div data-type="image" data-url="<url1>" class="nocache"></div>
<div data-type="image" data-url="<url2>" class="nocache"></div>

nicht funktioniert mit:
<div class="nocache">
<div data-type="image" data-url="<url1>" class=""></div>
<div data-type="image" data-url="<url2>" class=""></div>
</div>

Etwas allgemeiner formuliert: Das "nocache" muss in dem div stehen, in dem es wirken soll. Kann man das so allgemein sagen? Wenn ja, könnte das in die Beschreibungsvorlage zu nocache. Ich selbst habe das erst nach Wochen und mit Hilfe von Setstate erkannt und verstanden. Anderen möchte ich das ersparen.

P.S. Damit bleibt im Dunkeln, warum das ?_=3455543 in der URL Wunderkräfte entwickelte, aber egal.

Code Auswählen Erweitern

<div class="nocache">
<div data-type="image" data-url="http://www.dwd.de/DWD/wetter/radar/radfilm_nrw_akt.gif?_=3455543" data-refresh="900"></div>
</div>

[drhirn]

Oder so z.B.?

[Ulm32b]

Oder so z.B.?

Schon recht. Mein Denkfehler war, dass nocache nicht in das umklammernde div durfte, wozu man verleitet wird, wenn mehrere Bilder (die ggf. auch aus- und eingeblendet werden, um somit einfaches Umschalten zu ermöglichen) aufeinanderfolgen. Für mich ist das Thema durch. Wie ich schon sagte, ich möchte es anderen erparen.

[Nobby1805]

Hallo,
ich möchte die Sache mit den CSS-Klasse noch einmal hochkochen. Bislang gibt es keinen Vorschlag, wie wir das effizient auf die Reihe bekommen. Wie wäre es mit folgendem Ansatz:
Jemand ( ) erstellt eine FTUI-Seite und unterteilt diese schachbrettartig. In die einzelnen Felder kommt:

Wenn sonst niemand ganz laut "ich will" schreit, dann mache ich mir mal Gedanken, wie man das Ganze (teil-)automatisiert erstellen kann ... im Sinne der nach dem Vorschlag folgenden Diskussion: gebt mir ein paar Tage Zeit, es ist ja nicht ganz so eilig

[drhirn]

Knob ist fertig: https://wiki.fhem.de/wiki/FTUI_Widget_Knob

Geht ich richtig in der Annahme, dass data-hdcolor und data-width keinerlei Effekt haben?

Und könnte sich bitte jemand einen sinnvollen Einleitungstext überlegen? Ich hab keine Ahnung, wie ich beschreiben soll, was das Widget macht.