Ich tue mir gerade etwas schwer beim Testen.
Compile funktioniert schon mal ;)
Aber wenn ich da eine "alte" Config in
lib_version="8" öffne, sollte das doch laut Code irgendwie nach 9 konvertiert werden? Bei mir passiert nichts, auch heißt es beim Check, dass alles passt
Also da sollte dann ein Dialog kommen der auf eine veraltete Version hinweist und darin ein Link der dann den Manager öffnet, das Upgrade vornimmt und Dir die vorgenommenen Änderungen anzeigt, die kannst Du dann wiederum einfach abspeichern lassen oder erstmal selbst überprüfen (wonach Du dann selbst speichern musst). Das hat eigentlich auch funktioniert, hab ich ja sicherlich 50mal gemacht. Sicher, dass in der geladenen Config auch die Version 8 steht? Mir passiert das gerne mal dass ich was in source/resource/config ändere und mich dann wundere dass nichts passiert, weil ich nicht neu kompiliert (bzw. nicht dem Compiler mit —watch anhatte) und somit die Änderungen nicht ins Compiler-Verseichnis kopiert wurden.
Ansonsten wäre das schon die Hauptsache die da getestet werden müsste. Halt alles was mit fehlerhaften Configs zu tun hat und ggf. noch auf die alten PHP-Dateien verweisen würde (Config-Check, Upgrader, usw.). Auch mal eine Config mit fehlerhafter Syntax laden (also invalides XML, so dass der XML Parser des Browsers auf die Nase fällt), dann sollte auch eine Fehlermeldung kommen und ein Link auf der die Config im Text-Editor des Managers öffnet und direkt zum ersten Fehler springt.
Beim Upgrader habe ich jetzt nur die letzten beiden Versionen implementiert (also ab 7) für ältere müsste man weiterhin den PHP-Upgrader nutzen. Ich wusste einfach nicht ob noch so alte Versionen im Umlauf sind, dass sich das lohnt, da ältere Versionen zu implementieren.
@peuter beim Versuch https://knx-user-forum.de/forum/supportforen/cometvisu/1517419-anf%C3%A4ngerfrage-widget-anpassen#post1517419 nachzustellen ist mir mit dem neuen Compiler aufgefallen/passiert:
- Compiler läuft mit Watch
- per
vim source/resource/config/media/custom_switch.cssdie CSS Datei angelegt und befüllt - Compiler meldet
Cannot find library for config/media/custom_switch.css cv ll compiled/source/resource/config/media/zeigt, dass die Datei nicht übernommen wurde
- Config öffnen
- dort Manager öffnen
- dort eine andere Config öffnen (geht auch nur unkomfortabel indirekt über Burger-Menü -> Öffnen mit... -> Konfiguratio...)
- die wird nun nicht statt der ersten oder statt dem Manager sondern im Manager über der ersten geöffnet
- der (wegen falscher Lib auch erwartete) Dialog hat nun einen Bug, s.o.
=> Ich denke wir sollten hier wieder die klare Zweiteilung einführen, entweder CV oder Manager.
Dabei spricht ja nichts dagegen, dass Strg+M hier den Link aufruft
Das zusammen zu wursteln gibt nur eine Komplexität die uns keinerlei Mehrwert liefert
Es wäre deutlich mehr Arbeit, das nun wieder künstlich zu trennen als die paar Bugs zu fixen die da noch drin sind. Es liefert momentan noch keinen allzu großen Mehrwert (außer dass sofern ich das richtig erinnere einige Daten für die Dataprovider direkt aus dem geladenen Code der CometVisu entnommen werden, z.b. welche Plugins/Designs es gibt). Durch die momentane nahtlose Integration hat man aber in der Zukunft mehr Möglichkeiten.
Ich habe jetzt folgende Anpassungen vorgenommen:
- Es gibt einen extra Button zum Öffnen einer Config, diese wird dann nicht mehr als Tab im Manager sondern in einem neuen Fenster geöffnet, damit sollte das Problem der verschachtelten Navigation behoben sein und zudem das Öffnen besser zugänglich sein
- Die fehlerhafte URL zum Ignorieren der falschen Lib ist gefixt
Komisches Problem: wenn ich im Manager auf den XML-Editor gehe, so funktioniert das bei meiner Test-Umgebung bei 3 von 4 Configs:
Nur bei test_slider geht es nicht, gleichzeitig kommt die (untere) 404 Meldung.
D.h. der möchte anscheinend die falsche Config öffnen
Dabei gibt es zwischen den Dateien für mich keinen nachvollziehbaren Unterschied:
das sollten wir aber besser abfangen, sonst bekommen wir das nicht supportet
@peuter zur Info: bei cometvisu/cometvisuabstractbase habe ich etwas erweitert:
- Der Apache-Access-Log kann über
ACCESS_LOGdeaktiviert werden (hatte früher die TWS voll und überlaufen lassen; ist dort zwischenzeitlich anders gelöst, aber wir haben ja auch andere Anwender) - der Healthcheck ist jetzt implementiert
- über
STOP_ON_BAD_HEALTHlässt sich bereits beim ersten mislungenen Health checke der Container beenden. Und somit über die Docker config automatisch wieder starten. (Ein Auto-Starten basierend auf dem Health Status kann Docker leider noch nicht)
Das ganze dürfte dann ab den nächsten Container-Bauen im produktiven Bereich ankommen
@peuter der Qx Compiler macht einen komischen Fehler: Er läuft mit Watch, dann erzeuge ich mit Inkscape eine SVG im Projekt - und dann kommt eine Beschwerde wie
Beende ich den Compiler und starte ihn wieder neu (aktuell mit
Cannot find library for plugins/clock/clock_template2.svg. Die Datei wird auch nicht kopiert.Beende ich den Compiler und starte ihn wieder neu (aktuell mit
npx qx compile -c --clean --watch), dann passt es mit dieser Datei.
@peuter ich versuche gerade (endlich...) das Clock-Plugin fertig zu machen und dazu die Doku zu schreiben. Wenn ich die Screenshots lokal erzeugen will gibt's einerseits bei
grunt screenshots in der Konsole Fehlermeldungen (CSS Regel funktioniert nicht). Zum anderen zeigt der Firefox bei grunt screenshotsManual diese Fehlermeldung, die evtl. damit auch zu tun haben kann
Hattest Du nicht die Library-Version hoch gesetzt?
Vermutlich müsste nun irgendwo ein Template o.ä. angepasst werden.
Wo wäre dass denn?
@peuter nächste Frage :) - ich will gerade das ControllerInput Plugin (Bestandteil vom ceramic Design) wieder zum Laufen zu bringen. Scheitere aber daran, dass die Datei
Wo kommt denn her, dass die
/resource/plugins/controllerinput/index.js geladen werden soll, die es nicht gibt und daher natürlich einen 404 wirft. Die ControllerInpus.js wird weiter oben erfolgreich geladen.Wo kommt denn her, dass die
controllerinput/index.js geladen werden soll? Die haben wir bei keinem unserer Plugins...
Das ist das Fallback auf die "alte"-Variante vor der Qx-Umstellung. Damit werden Plugins geladen die dem System komplett unbekannt sind. Damit ist es weiterhin möglich, dass jemand mit einem lokal installierten Release der CometVisu ein eigenes Plugin entwickelt. Du musst vermutlich einfach den Part für das Plugin deklarieren, irgendwo hier: https://github.com/CometVisu/CometVisu/blob/develop/compile.json#L54 ?
Wenn der Code so alt ist, dass der das alles nicht mehr berücksichtigt ist's nur um so dringender, dass der endlich fertig wird
2020 ist schon ein ganz komisches Jahr. Mit HomeOffice sollte mangels Pendeln eigentlich deutlich mehr Zeit zur Verfügung stehen - aber gefühlt ist's irgendwie deutlich weniger :O
@peuter eine Frage zum Plugin/Parts und Qx-Klassen-System: der ControllerInput soll unter dem Bedienwidget selbst einen kleinen Graphen als Sparkline haben. Hierzu das Diagram-Plugin zu doppeln macht ja keinen Sinn.
=> Wie wäre denn ein sinnvolles Vorgehen für maximale Wiederverwendung des Codes?
Also so, dass Flot (oder irgend eine zukünftige Graph-Bibliothek) nur 1x geladen wird.
Evtl. mit Mitverwendung von AbstractWidget (keine Ahnung ob hier die Schnittmenge groß genug ist oder eine Parallel-Implementierung von der Lesbarkeit und dem Code-Umfang sparsammer wäre). Was dann aber wohl bedeuten würde, dass ein Plugin (ControllerInput) das Laden eines anderen Widgets (Diagram) erzwingen würde...
=> Wie wäre denn ein sinnvolles Vorgehen für maximale Wiederverwendung des Codes?
Also so, dass Flot (oder irgend eine zukünftige Graph-Bibliothek) nur 1x geladen wird.
Evtl. mit Mitverwendung von AbstractWidget (keine Ahnung ob hier die Schnittmenge groß genug ist oder eine Parallel-Implementierung von der Lesbarkeit und dem Code-Umfang sparsammer wäre). Was dann aber wohl bedeuten würde, dass ein Plugin (ControllerInput) das Laden eines anderen Widgets (Diagram) erzwingen würde...
Also das zu einer Art Abstraktem-Package machen das dann sowohl das Diagram als auch der ControllerInput laden würden wenn die eingebunden werden?
Auch das macht das Part-Management von Qx automatisch. Das was man in der Config als Parts deklariert entspricht nicht zwingend den tatsächlich erzeugten Parts. Wenn nun
Wie sich das verhält müsste man dann mal im Auge behalten.
AbstractDiagram von mehreren Parts (aka Plugins) benutzt wird, dann wird das entweder in einen extra Part gepackt oder, wenn es wirklich nur diese einzelne Klasse ist mit in den Boot-Part gepackt, weil der Overhead einen extra Part dafür zu machen und laden zu müssen zu groß wäre. Was mit aber gerade noch einfällt ist, dass ich da mal was gebastelt habe, dass beim Kompilieren diese externen Libraries mit an den generierten Part dranhängt. Der hat also die ganzen Flor-JS-Dateien drangehängt, damit nicht erst der Part für das Plugin und danach noch die ganzen JS-Libs einzeln geladen werden müssen sondern alles in einem Request.Wie sich das verhält müsste man dann mal im Auge behalten.