CometVisu/CometVisu_DE

Deutschsprachiger Raum für die CometVisu

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.

Christian Mayer

@ChristianMayer

@peuter das Thema ist ganz komisch. Um dem etwas näher zu kommen bin ich zurück zu devlop, neuer Branch für Tests erstellt. Dort compiliert, ControllerInput gibt es nicht. Mit npx qx compile -c --clean --watch compiliert, die normale Demo-Config geöffnet --- und trotzdem kommt die Fehlermeldung

ControllerInput.js:34 Uncaught TypeError: Cannot read property 'diagram' of undefined
    at ControllerInput.js:34
    at ControllerInput.js:1

?!?!?!?

Nun, im compiled-Verzeichnis liegt zwar eine ./transpiled/cv/plugins/ControllerInput.json und ./transpiled/cv/plugins/ControllerInput.js - aber der compilte Rest sollte die doch nicht (mehr) kennen und folglich der Browser auch nicht

(Und hätte das --clean das nicht weg löschen müssen?)

Christian Mayer

@ChristianMayer

Es wird noch seltsamer: Nun habe ich compiled/source/geleert, neu compiliert - und die Visu beschwert sich im Browser mit

?config=demo&forceReload=true:72 GET https://timberwolf76.local/proxy/visugit/obiwan/cv/boot.js net::ERR_ABORTED 404

Sie scheint aber trotzdem normal zu funktionieren

Christian Mayer

@ChristianMayer

Noch mehr Analyse, ich habe das gleiche Problem wie beim ControllerInput, nur minimal anders ausgeprägt:

Immer mit Demo Config, also eine Konfig die nichts mit dem neuen, zusätzlichen Plugin zu tun hat. Dann gibt es zwei möglichkeiten:

Entweder es gibt eine Fehlermeldung aus der Browser-Konsole, aber die Darstellung der Visu passt
Oder es gibt die Fehlermeldung nicht, die Darstellung passt aber auch nicht (Widgets haben eine resultierende Breite von 0)

Christian Mayer

@ChristianMayer

Was ich noch entdeckt habe ist im ersten Fall, neben dem Fehler auf der Browser-Konsole

?config=demo&forceReload=true:72 GET https://timberwolf76.local/proxy/visugit/obiwan/cv/boot.js net::ERR_ABORTED 404

erscheint beim Compiler diese Warnung:

Warning: There is no reference to index.js script in the index.html copied from /home/cm/devel/CometVisu/CometVisu/source/boot/index.html (see https://git.io/fh7NI)

Im zweiten Fall ist nicht nur die Meldung im Browser sondern auch die Meldung vom Compiler weg.
Und es ist weiterhin so, dass sich diese beiden Zustände mit jedem Compiler-Lauf abwechseln.
(Da https://git.io/fh7NI nur ein 404 liefert weiß ich nicht was Qx mir da sagen möchte)

Christian Mayer

@ChristianMayer

Test habe ich mit https://github.com/CometVisu/CometVisu/compare/develop...ChristianMayer:test_plugin_diagram_derivative durchgeführt

Christian Mayer

@ChristianMayer

Zurück zu develop - und das gleiche Problem :O

Aber, evtl. habe ich nun einen Ansatz: mit npm ci habe mein NPM mal auf den Lock-Zustand gezwungen. Nun scheint mein Test-Plugin ohne das beschriebene Problem zu funktionieren (zumindest 2x compilieren gab keine Fehlermeldung und auch nicht das Problem mit der resultierenden Breite von 0)

Tobias Bräutigam

@peuter

Ich hatte noch nicht die Zeit mich wieder mit dem Thema zu beschäftigen. Aber der letzte Satz klingt doch schon mal recht vielversprechend.

Where communities thrive

People

Repo info

Activity