Hi,
aus dem CalView Wiki habe ich das Beispiel am Ende genommen ud mit wenig Änderungen erfolgreich ans Laufen gebracht :)
Ich nutze 5 Kalender und die DaysLeft Optionen. Dadurch ist SourceColor ja nicht mehr sinnvoll nutzbar.
Ich möchte nun in der ersten Spalte abgeleitet aus dem Attribut "source" ein Bild anzeigen (Der erste Buchstabe des Vornames im Kreis, farblich unterschiedlich)
Mittels css klasse könnte man ein hintergrundbild definieren, finde aber keine möglichkeit in einer Spalte auf Basis "source" eine klasse einzubinden.
Hat jemand irgendwelche ideen?
Ohne Weiteres wird es für die angestrebte Darstellung vermutlich keine direkte Lösung geben.
Um eine Lösung zu bekommen, müssen einige Dinge neu geschaffen werden:
Das CALVIEW-Device muss (mindestens) ein zusätzliches Reading pro Termin bereitstellen, in dem die class-Angaben enthalten sind. Rein theoretisch kann für jede Spalte ein derartiges Reading existieren. Momentan muss ein derartiges Reading vom Anwender generiert werden; später vielleicht auch - zumindest eingeschränkt - vom CALVIEW-Modul. Für Testzwecke habe ich Readings nach dem Muster t_nnn_sourceclass angelegt - der Name ist völlig frei festlegbar.
Das CALVIEW-Widget muss ein neues Attribut bereitstellen, so dass die gewünschten Klassen nach Auswertung der oben erwähnten Readings angewendet werden können. Beim Testen/Nachdenken habe ich noch ein zweites Attribut eingeführt, so dass eine Spalte bei allen Terminen immer identisch klassifiziert werden kann - ganz ohne spezielles Reading.
Ein Test brachte den Ausgangszustand (Darstellung_vorher) und den angepassten Zustand (Darstellung_nachher) zu Tage. Die erste Spalte wurde im neuen Zustand abhängig vom angegebenen Reading (gelber Punkt) und die zweite Spalte immer gleich (grüner Punkt) dargestellt.
Die Frage ist jetzt, ob Du mit einer solchen Lösung zu Deinem Ziel kommen würdest oder ob das Problem falsch verstanden wurde?
Hi,
so ungefähr passt das, ich habe aber nochmal selbst probiert was mit dem aktuellen Stand möglich ist. Ich habe es fast geschafft, leider wird das Reading "sourcecolor" im widget sonderbehandelt. aber mal der reihe nach:
Im CALVIEW Modul folgendes erstellt:
defmod CALVIEW_Family CALVIEW CAL_Tobi,CAL_Alex,CAL_Cedric,CAL_Linus next
attr CALVIEW_Family DbLogExclude .*
attr CALVIEW_Family modes next
attr CALVIEW_Family room Kalender
attr CALVIEW_Family sourcecolor CAL_Tobi:<img class='cal_image' src='images/Letter-T-gold-icon.png'>,CAL_Alex:<img class='cal_image' src='images/Letter-A-violet-icon.png'>,CAL_Cedric:<img class='cal_image' src='images/Letter-C-blue-icon.png'>,CAL_Linus:<img class='cal_image' src='images/Letter-L-lg-icon.png'>
Meine Widget Definition:
<div data-type="calview"
data-device="CALVIEW_Family"
data-class-usage="row"
data-daysleft-values='[0,1]'
data-daysleft-classes='["",""]'
data-detail='["sourcecolor","weekdayname","bdate","timeshort","summary"]'
data-detailwidth='["5","10","10","10","65"]'
data-get="all"
data-header='["","","Datum","Zeit","Zusammenfassung"]'
data-max="10"
data-oneline="yes"
data-showempty="Derzeit keine Termine"
>
</div>
Im CalView Modul wird der html code korrekt erstellt. Allerdings im Widget funktioniert es nicht. Benenne ich die Readings im Modul zb. von "t_nnn_sourcecolor" nach "t_nnn_sourceclass" um und ändere dementsprechend in der widgetdefinition "sourcecolor" nach "sourceclass", wird alles korrekt angezeigt.
Das Bild zeigt das Ziel, wenn ich sourcecolor nach sourceclass ändere. Perfekt wäre es wenn "sourcecolor" gernauso interpretiert werden würde....
Im heutigen Modulstand reicht im Widget die Verwendung des sourcecolor-Attributes für die ursprünglich angedachte Interpretation des sourcecolor-Feldes (Integration als class) vollkommen aus. Früher musste das sourcecolor-Feld auf jeden Fall auch im detail-Attribut enthalten sein, aber nicht für die Ausgabe, sondern lediglich für die Abonnierung; folglich wurde das sourcecolor-Feld nie dargestellt. Irgendwann hatte ich die Pflege des Moduls übernommen und auf den heutigen Stand gebracht. Zum Schutz älterer Oberflächen musste aber immer noch dafür gesorgt werden, dass das sourcecolor-Feld ignoriert wird.
Mittlerweile ist ja doch relativ viel Zeit seit der Umstellung vergangen und auch keine offizielle Verteilung mehr möglich; man könnte also einfach die Sperre für das sourcecolor-Attribut entfernen und kommt vollständig mit der ansonsten vorhandenen detail-Logik zurecht.
Es sollte dann ausreichen, dass Du im Widget für Testzwecke einfach die 3 existierenden Problemstellen ersetzt :
alle Stellen mit
== 'sourcecolor'
ersetzen durch
== 'source____color'
Wenn diese Änderung zu Deinem Ziel führt, würde ich eine entsprechend angepasste Änderung auch in den letzten (offiziellen) Modulstand übernehmen.
Hi,
GENAUSO funktioniert es jetzt :) Habe im Widget die stellen geändert wie von dir oben beschrieben.
So sieht es jetzt aus :)
Für das offizielle Widget:
Entweder müsste sourcecolor jetzt einen neuen Namen bekommen da es jetzt ja ein ganz normales Attribut ist, oder ein neues Attribut muss ins Modul rein mit identischer Modul Funktionalität von Sourcecolor, also für jeden Termin pro Kalenderquelle
Das sieht wirklich gut aus und erfordert im FTUI-Widget keinen größeren Eingriff.
Das Reading sourcecolor würde ich genau so lassen - also kein Umbenennen o.ä., da die meisten das Reading als Farbwert verstehen und verwenden.
Wir sollten tatsächlich das FHEM-Modul um mindestens 2 source-Readings erweitern (lassen) - sourceclass und sourcehtml oder freier verwendbar als source1 .. source9. Generieren ließen sich diese zwar auch heute schon als userreading, aber der Weg über das FHEM-Modul macht die Sache doch deutlich einfacher und man spart sich einen Teil des FHEM-Moduls nachprogrammieren zu müssen.
Wenn das jetzt ein gangbarer Weg wäre, sollten wir im passenden Beitrag eine Anfrage stellen ...
Im Widget teste ich ein wenig mit 2 neuen Widget-Attributen, über die JEDE Spalte bzgl. class beeinflusst werden kann (fix oder mit Reading).