CometVisu/CometVisu_DE

Deutschsprachiger Raum für die CometVisu

Tobias Bräutigam

@peuter

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.

Tobias Bräutigam

@peuter

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

Christian Mayer

@ChristianMayer

@peuter zu #1029:

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:

Tobias Bräutigam

@peuter

Wie sieht der der Link zum Schema in der Datei aus, sieht so aus als ob da das .. / fehlen würde.

Christian Mayer

@ChristianMayer

Du meinst das

<pages lib_version="8" design="pure" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="./visu_config.xsd">

Christian Mayer

@ChristianMayer

OK, Volltreffer, das wars

das sollten wir aber besser abfangen, sonst bekommen wir das nicht supportet

Christian Mayer

@ChristianMayer

@peuter

@peuter zur Info: bei cometvisu/cometvisuabstractbase habe ich etwas erweitert:

Der Apache-Access-Log kann über ACCESS_LOG deaktiviert 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_HEALTH lä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

Tobias Bräutigam

@peuter

:+1:

Christian Mayer

@ChristianMayer

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

Tobias Bräutigam

@peuter

Vielleicht müssen wir mit dem Compiler mal wieder auf die aktuellste Version gehen. Ist ja noch Beta und es tut sich da noch recht viel.

Christian Mayer

@ChristianMayer

@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?

Christian Mayer

@ChristianMayer

Hab's gefunden, jetzt geht's :)

Christian Mayer

@ChristianMayer

@peuter magst Du auf die PRs #1030 und #1031 schauen? Vermutlich absolut i.O., aber ich kann nicht abschätzen ob die irgendetwas im Build-Prozess o.ä. kaputt machen würden...

Christian Mayer

@ChristianMayer

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

Tobias Bräutigam

@peuter

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 ?

Christian Mayer

@ChristianMayer

Danke, das war's!

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

Christian Mayer

@ChristianMayer

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

Tobias Bräutigam

@peuter

Wenn die JS-Dateien mit cv.util.ScriptLoader geladen werden (siehe Diagram-Plugin) dann sollte das automatisch so sein, dass nichts doppelt geladen wird. Der benutzt unter der Haube qx.util.DynamicScriptLoader und der sorgt dafür (zumindest hab ich das so in Erinnerung).

Christian Mayer

@ChristianMayer

Kann ich auch irgendwie das AbstractDiagram (hatte ich oben schon gemeint, aber falsch aufgeschrieben) wiederverwenden?

Also das zu einer Art Abstraktem-Package machen das dann sowohl das Diagram als auch der ControllerInput laden würden wenn die eingebunden werden?

Tobias Bräutigam

@peuter

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

Christian Mayer

@ChristianMayer

Wenn ich AbstractDiagram in ein extra Part schieben würde - wie muss ich Qx die Abhängigkeit des Diagram und ControllerInput Parts von dem AbstractDiagram mitteilen? Ich vermute, dass das Qx Class extend dafür nicht ausreicht, oder?

Tobias Bräutigam

@peuter

Du musst da gar nichts selbst machen, auch keinen extra Part definieren.

Christian Mayer

@ChristianMayer

ok, dann hab ich's nicht verstanden
Aktuell lebt die AbstractDiagram Klasse im selben Ordner wie die beiden Diagram-Source-Dateien - und bilden somit einen Part. Denke ich.

ok, dann hab ich's nicht verstanden

Tobias Bräutigam

@peuter

Das hat nichts mit der tatsächlichen Position der Datei zu tun, das hängt nur von den jeweiligen Abhängigkeiten ab.

Christian Mayer

@ChristianMayer

D.h. ich schreibe im ContolerInput einfach im extends das AbstractDiagramhin?

Tobias Bräutigam

@peuter

:+1:

Christian Mayer

@ChristianMayer

Und wann lädt Qx die (dicke) Flot-Bibliothek, von der AbstractDiagram abhängt?

Tobias Bräutigam

@peuter

Im Normalfall wenn der JS-Code der AbstractDiagram-Datei geladen wird. Im Build müsste wir dann nochmal nachschauen ob meine Optimierung mit der Einbettung der Bibiotheken damit umgehen kann, sollte aber eigentlich genauso sein.

Christian Mayer

@ChristianMayer

OK, ich versuche mal mein Glück

Christian Mayer

@ChristianMayer

So ganz funktioniert das noch nicht.

ControlerInput.js:

...
qx.Class.define('cv.plugins.ControllerInput', {
  extend: cv.plugins.diagram.AbstractDiagram, // cv.ui.structure.AbstractWidget,
  include: [cv.ui.common.Update, cv.ui.common.Operate],
...

und in der Test-Config

    <plugins>
      <plugin name="diagram"/>
      <plugin name="controllerinput"/>
    </plugins>

=> Es wird in der richtigen Reihenfolge geladen, aber die Zeile 34 (= genau die mit dem extend: cv.plugins.diagram.AbstractDiagram) wirft einen Fehler

Nehme ich aus der Config das <plugin name="diagram"/> heraus bleibt das Problem gleich - es wird aber nicht mal AbstractDiagram.js geladen

Tobias Bräutigam

@peuter

Hm, vielleicht mal den Part für das Diagram so ändern, dass die AbstractDiagram.js da nicht mehr explizit mit drin ist.

"plugin-diagram": {
      "include": [
            "cv.plugins.diagram.Info",
            "cv.plugins.diagram.Diagram"
      ]
 }

Where communities thrive

People

Repo info

Activity