CometVisu/CometVisu_DE

Deutschsprachiger Raum für die CometVisu

Christian Mayer

@ChristianMayer

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"
      ]
 }

Christian Mayer

@ChristianMayer

Komisch was nun passiert.
1) es funktioniert schon mal besser. Die ControllerInput-Klasse scheint grundsätzlich zu laufen (der DOM-Tree ist an der entsprechenden Stelle nicht mehr leer).
2) es kommt weiterhin Uncaught TypeError: Cannot read property 'diagram' of undefined - aber bevor alles andere in der Konsole kommt?!?

3) es wird - obwohl die Konfig kein <plugin name="diagram"/> enthält - auch AbstractDiagram.js geladen. Allerdings deutlich nach dem ControllerInput.js. Müsste das wegen der Abhängigkeiten nicht umgedreht passieren?

(Zeile VM19466 ControllerInput.js:72 ist wieder das extend: cv.plugins.diagram.AbstractDiagram)

Tobias Bräutigam

@peuter

Die falsche Reihenfolge aus 3) wird die Ursache für 2) sein. Die Frage ist nun warum. Es gibt normalerweise Dateien im compiled-Verzeichnis in denen der Compiler die Anhängigkeiten, die er erkannt hat speichert. Ich weißt gerade nur nicht mehr auswendig wie die heißen und ob man das noch irgendwo aktivieren musste, dass diese Dateien erzeugt werden. Kannst Du den aktuellen Stand mal commiten, dann kann ich mir das selber mal anschauen.

Tobias Bräutigam

@peuter

Also ich habe das jetzt mal kurz ausprobiert mit einer leeren Config und nur dem controllerinput Plugin (ohne es zu benutzen) und die Ladereihenfolge ist korrekt. Vielleicht machst Du einfach mal ein Clean, oder aber Du hast da noch weitere Änderungen drin. Ich habe den Stand aus dem PR ausgecheckt und nur das extend der ControllerInput-Klasse geändert und die Part-Definition des Diagram Plugins wie oben angegeben geändert. Grundsätzlich funktioniert das also wie gedacht.

Christian Mayer

@ChristianMayer

Ich starte den Compiler immer mit npx qx compile -c --clean --watch d.h. der Build ist neu.
Gerade hat es bei mir auch funktioniert. Auch bei mehreren Browser reloads. Also gleich Compiler mal beendet und wieder gestartet. Dieses geht's nicht mehr, Fehlermeldung, falsche Reihenfolge der beiden JS-Dateien. Auch bei mehreren Browser reloads.
=> Hier scheint die Reihenfolge beim Compilen per Zufall zu entstehen und nicht determinstisch durch die Abhängigkeitsreihenfolge.

Christian Mayer

@ChristianMayer

Nachtrag: es braucht nicht mal einen Neustart des Compilers. Es reicht wenn der im Hintergrund auf neue Arbeit wartet und dann in der ControllerInput.js minimal etwas verändert wird, so dass der Compiler loslegt.

Christian Mayer

@ChristianMayer

Was erstaunlich ist: bei jedem Compile-Vorgang wechselt es zwischen geht und geht nicht. Also nicht mit 50% Wahrscheinlichkeit zufällig, sondern wirklich streng abwechselnd. (Mag auch per Zufall so kommen, aber die Wahrscheinlichkeit für exakt abwechselnd ist bei der Anzahl von Versuchen die ich inzwischen durch habe schon sehr gering)

Christian Mayer

@ChristianMayer

Und es wird noch komischer: Wenn die Fehlermeldung Uncaught TypeError: Cannot read property 'diagram' of undefined nicht(!) kommt, dann ist das Layout der Configs kaputt. Auch von Konfigs wie der demo-Config die mit der ganzen Änderung nichts zu tun hat.
Wenn der Compiler dann den anderen Zustand erzeugt, also die Fehlermeldung Uncaught TypeError: Cannot read property 'diagram' of undefinedangezeigt wird, dann ist das Layout in Ordnung

Ich habe meinen aktuellen Versuchs-Stand committed. Ist aber wohl exakt der gleiche Stand wie Dein Versuch

Tobias Bräutigam

@peuter

Tut mir leid ich kann den Fehler nicht reproduzieren, ich habe alles genauso gemacht wie Du das beschrieben hast und kann beliebige Änderungen am Code machen, dass wird immer korrekt geladen, ich habe einfach die leere Default-Config um das hier erweitert (+ Angabe des Plugins natürlich):

<controllerinput>
    <address transform="raw">Test</address>
    </controllerinput>

Das lädt jedesmal ohne Fehler. Vielleicht kannst Du mal vergleichen ob es Unterschiede gibt zwischen funktionieren und nicht funktionieren in folgenden Dingen:

compiled/source/db.json da müsste sowas drin stehen:

"cv.plugins.ControllerInput": {
   "mtime": "2020-11-20T05:10:20.667Z",
   "libraryName": "cv",
   "dependsOn": {
     "qx.Class": {
       "load": true,
       "usage": "dynamic"
     },
     "cv.plugins.diagram.AbstractDiagram": {
       "load": true
     },

compiled/source/boot.js in den Package/Part Definitionen ist bei mir die AbstractDiagram.js in einem Package mit den ganzen anderen Widgets (ja das sollte später nicht mehr so sein, aber für den Moment erstmal egal):
```
packages : {
....
"40": {
 "uris": [
 ....
 "../transpiled/cv/plugins/diagram/AbstractDiagram.js",
....
],
...
"65": {
 "uris": [
   "../transpiled/cv/plugins/ControllerInput.js"
 ]
},
...
]
```
Und Package 40 ist mit im boot-Part:
```
qx.$$loader = {
parts : {
"boot": [
....
"40",
....
"plugin-controllerinput": [
 "65"
],
....
]
```
Zur Erklärung: Der boot-Part ist der der zum Start immer geladen wird. Und der wird auch immer zuerst geladen. Vielleicht hilft Dir das irgendwie der Sache auf den Grund zu gehen, denn ich kann es ja wie gesagt nicht nachstellen.

Where communities thrive

People

Repo info

Activity