Graphen: geändertes Template mit direkter Farbzuweisung

Hallo,
erstmal vorab: Das WIIPS ist ein tolles Tool. Natürlich habe ich nach wenigen Tagen Test noch längst nicht alles erkunden können, aber der Sinn ist verstanden und sofort in Nutzung übernommen worden :slight_smile:

Natürlich habe ich auch einiges anzumerken, teilweise auch im Status „Killerkriterium“. Natürlich habe ich dazu erstmal nach der erfolglosen Suche in Doku/Wiki

  • das Forum hier durchforstet (und meine Probleme als oft und schon lange gefragt wiedergefunden)
  • mit den Entwicklern Kontakt aufgenommen
    (Antworten bei beiden: Problem erkannt / Lösung nur nichttrivial, ergo jetzt nicht möglich )

…und daraufhin heute dann eben selbst mal fix eine (m.E. solide!) Lösung erarbeitet und in den Anhang dieses Beitrags gelegt :wink:

Problem:
Die Farbzuweisung beim Editieren von Graphen ist zwar mit der integrierten Color-Picker-Funktion recht intuitiv und schick, aber leider nicht reproduzierbar. Sprich: Ein weiteres Mal per Klick genau den gleichen Farbwert zu treffen (z.B. für den funktional identischen, wertemäßig aber total differierenden Ist-Temperaturwert des Nachbarraums) ist illusorisch.

Hinzu kommt, das jeder 6. männl. Bewohner dieses Erdballs (meist ohne es zu wissen) an Rot/Grün-Schwäche leidet, und als Betroffener ist es für mich bereits unmöglich, rein graphisch bestimmte Grundtöne auseinanderzuhalten („war der Istwert nun Rot oder grün“ --> aha, „nicht-blau“) --> Das WIIPS-Tool wäre ergo ohne exakte Rücklesbarkeit / Eingebbarkeit der Farbwerte für mich nicht einsetzbar und nutzbar, so auch „normalsichtige“ meine Graphen sehen und verstehen können sollen.

Völlig ausreichend wäre es (als workaround) gewesen, zumindest den „Altwert“ erst einmal sichtbar hinzuschreiben (da dort eine Box in initial dieser Farbe erscheint, MUSS er an der Stelle intern bekannt sein), denn dann könnte man zumindest schon mal „annähernd den Wert versuchen zu treffen“ (im Colorpicker wird der neue Wert hingeschrieben / ist zumindest lesbar, wenn Farbe hell genug)

10min Suche im System zeigten mir das betroffene Template (IP-SYMCON\WEB\TEMPLATES\DEFAULT\RRD\rrd_conf_edit.html) sowie den zutreffenden Variablenwert ($rgb).
Die im Template am Farbfeld vorhandene HTML-Tabelle um eine Zeile mit dessen Text-Ausgabe zu erweitern, brauchte eine weitere Minute.
Ergänzend habe ich auch noch gleich eine Farbzelle hinzugefügt, die immer auf dem Originalfarbton stehen bleibt (die Altfarben-Zelle wechselt merkwürdigerweise bei jedem Klick im Colorpicker auch ihre Farbe, obwohl bereits die Randfelder des Pickers in der angewählten Farbe stehen bleiben)
Ok, nun kann man alte und neue Farbe direkt untereinander vergleichen.

Hmmm… also wenn man da schon mal bei ist… Auch gleich mal versuchen, eine Direkteingabe des Farbwertes einzubauen? Chef schaut grad nicht her… :slight_smile:

Hat geklappt. Und besser als gedacht. Weil

  • alles alte (Colorpicker) weiter möglich / nicht angetastet
  • kein Ändern von vorhandenem JavaScript-Code notwendig
  • stabiler then ever (theoretisch), weil jetzt zusätzlich auch noch mit Werte-Check versehen

Die Lösung ist total simpel: Man nehme die bisher verdeckte Zielvariable und nutze diese als neues Eingabefeld. Nebeneffekt: Änderungen des Colorpickers sind inhaltlich dort sofort synchron sichtbar.

En detail:
Jeder per HTML-Form-Submit „abgesendeter“ Wert muß zuvor in einem vor/bei abgesenden gefüllten Input-Element gestanden haben. Schaut man einmal auf den Parameterstring beim Absenden (Eigenschaften / View page Info, oder wie auch immer in anderen Browsern der Punkt heißt), erkennt man, dass der Farbwert in einem Formelement namens „rgb“ als #-beginnender Hex-RGB-Wert steht (also „#rrggbb“, wie es in HTML üblich ist).
Als Form-Element mit diesem Namen kommt nur ein bestimmtes hidden-Element im oberen Bereich des Templates in Frage, das über seine ID „color1“ auch im Color-Picker-Umfeld angesprochen wird. Kurzer Test: Bingo
Hidden-Input-Element auskommentiert / neues gleichnamiges als Text-Input neben den Picker gesetzt: Voila!

Nachteil:
Der Picker sorgte durch seine Indirektheit bisher dafür, daß dort kein Blödsinn eingegeben werden konnte. Das ist dagegen bei einem Input-Element vom Typ „Text“ natürlich sehr wohl erstmal möglich. Eine Längenbegrenzung auf 7 Zeichen sorgt allein noch nicht dafür, daß

  • immer genau 7 Zeichen vorhanden sind
  • das erste Zeichen immer ein # ist
  • Zeichen 2-7 immer aus dem Bereich [0…9a…f] kommen

Aber meine aus alter Kramkiste hervorgeholte, und auf „onChange“ am Textfeld getriggerte JS-Funktion „checkRgb“ sorgt dafür. Bei irgendwelchen Fehlern setzt sie übrigens wieder den alten Wert ein. Ungefragt, damit nicht alles soviel quasselt wie ich :slight_smile:

Gruß und viel Spaß mit dem Teil
Gerd

PS: Mir ist natürlich nichts fremder, als unterschiedliche Versionen entstehen lassen zu wollen. Ich verstehe das nur als schnelle Hilfestellung und bitte die Entwickler, das (wenn notwendig auch abgeändert, z.B. JS-function in JS-Lib-File übernehmen?) in das eigentliche Projekt und dessen CVS zu integrieren.
Aus gleichem Grund habe ich das auch nur BEISPIELHAFT beim ÄNDERN von GRAPHEN angepaßt, und nicht auch noch am Wettermodul oder an den Neuzuweisen-Templates rumgespielt. Denn nun kann ich WIIPS wirklich einsetzen, und mehr wollte ich nicht.
Außerdem bin ich froh, auf diesem Weg vielleicht auch mal was dem Forum „zurückgeben“ zu können. Denn rausgelesen habe ich aus diesem Forum schon bedeutend mehr, und es lebt ja zunächst mal von Input, oder?

Last not least: Auch ich mach das „nebenberuflich“ und komme manchmal auch wochenlang nicht dazu, mich mit dem Hobby IPS oder dem Forum hier zu beschäftigen. Also bitte nicht bös sein, wenn ich auf Fragen nicht sofort reagieren sollte.

rrd_conf_edit.html.zip (2.34 KB)

Ich stimme dir zu. Es ist nicht einfach, die Farbwahl der Kurven immer richtig zu treffen. Ich habe deshalb auch den Colorpicker benutzt und die rrd.inc.php Datei manuell mit dem Notepad++ editiert mit den HexFarbcodes meiner Wahl.

Franz