CometVisu: next Generation

[peuter]

Nachdem das aktuelle Release (0.10.0) gerade veröffentlicht wurde, wird es Zeit mal vorzustellen woran wir gerade hinter den Kulissen arbeiten und wohin die Reise mit der nächsten Version der CometVisu gehen soll.

In der Regel gibt es in den meisten Software-Projekten einen Punkt an dem die Komplexität, des im Laufe der Jahre gewachsenen Source-Codes der Wartbarkeit ein wenig im Wege steht. So auch hier und mit der nächsten Version möchten wir dieses Problem beheben.
Um nun eine saubere Basis zu haben, wird die CometVisu künftig, auf dem Qooxdoo-Framework basieren (www.qooxdoo.org).

Dieses Framework liefert neben vielen anderen nützlichen Dingen eine Abstraktion der in Javascript vorhandenen Object-orientierten Features (die IMHO die Möglichkeit sauberen, wartbaren und abwärtskompatiblen Code zu erstellen annähernd unmöglich machen).

Das heißt also, in Zukunft werden sich einige Dinge ändern, die aber nur diejenigen betrifft, die z.B. Plugins, Designs oder anderes entwickeln. Denn diese Dinge müssen, sofern sie noch nicht Teil der CometVisu sind, ebenfalls umgeschrieben werden, um mit der nächsten Version zu funktionieren.

Für die normalen Nutzer wird sich im Idealfall nichts ändern. Aber unter der Haube alles neu ist, muss dies natürlich intensiv getestet werden. Zur Zeit ist die neue Version noch nicht Teil des CometVisu-Repositories. Sobald wir das Gefühl haben, das die Qualität hoch genug ist um es auf die Allgemeinheit loszulassen, wird sich das ändern.

Dieser Thread dient daher erstmal zu allgemeinen Information und Diskussion der Änderung.

[Chris M.]

Das heißt auch, dass unter dem aktuellen develop Branch wenig passieren wird, bis https://github.com/peuter/CometVisu/tree/next dort hinein gepullt wird.
Wenn es für die 0.10.0 notwendige Big-Fixes geben sollte (z.B. für das aktuelle Aufstart-Thema), dann werden die v.a. unter dem 0.10-Branch landen und von dort aus eine 0.10.1 erzeugt werden.

In der Zwischenzeit ist natürlich jeder eingeladen den Next-Branch anzusehen. Aber bitte Vorsicht: für reine Tester ist das - so lange es noch nicht in develop gelandet ist - noch nichts, wir sind aktuell dran das überhaupt Mainstream-Testbar zu machen.

[alltime]

Generell finde ich den objektorientierten Ansatz wesentlich schöner und verständlicher als den funktionalen Ansatz. Aber der Weg weg von jquery ist auch aufwendig und bringt nicht nur Vorteile:
Für neue Nutzer wird es immer schwerer Plugins oder Designs zu erstellen. Für Jquery gibt es einfach viel mehr Foren und Beispiele im Netz. Qooxdoo ist doch in vielen Details anders und hat und wird vermutlich auch nie so eine große Community wie jquery haben.
Auf der anderen Seite wird es durch mehr Objektorientierung vielleicht leichter Standard Cometvisu-Funktionen zu überschreiben/erweitern ohne die Source ändern zu müssen.

Noch ein Punkt, der den Einstieg von neuen Entwicklern deutlich erschwert ist "grunt". Vorher konnte man seine Änderungen sofort sehen. Dies war für mich auch ein riesen Vorteil der Cometvisu. Jetzt muss man zuerst alles "kompilieren". (Oder ist der dev-Sourcecode auch lauffähig ohne kompilieren? Dann wäre es nicht so tragisch).
Generelle Frage: bringt denn grunt so einen wesentlichen Performance-Gewinn?

Auf jeden Fall warte ich erst mal ab Plugins auf 0.10.0 umzustellen, da sie vermutlich für den nächsten Schritt komplett angepasst werden müssen.

Respekt an euch wie viel Gedanken, Arbeit und Zeit ihr in die CometVisu steckt!

LG Tim

[peuter]

Aber der Weg weg von jquery ist auch aufwendig und bringt nicht nur Vorteile:
Für neue Nutzer wird es immer schwerer Plugins oder Designs zu erstellen. Für Jquery gibt es einfach viel mehr Foren und Beispiele im Netz. Qooxdoo ist doch in vielen Details anders und hat und wird vermutlich auch nie so eine große Community wie jquery haben.

Für Plugins/Designs steht es jedem frei weiterhin auf jQuery zu setzten (gibt ja auch in 0.11.0 noch Plugins die das tun). Für einfache Dinge ist dies aber nicht mehr nötig, weil man alles was jQuery kann auch mit Qooxdoo machen kann. Wenn z.B. viele jQuery-Plugins genutzt werden, wäre das natürlich ein sehr großer Aufwand, daher muss man das auch nicht tun.

Auf der anderen Seite wird es durch mehr Objektorientierung vielleicht leichter Standard Cometvisu-Funktionen zu überschreiben/erweitern ohne die Source ändern zu müssen.

So ist es, das wird in der neuen Version wesentlich einfacher sein.

Noch ein Punkt, der den Einstieg von neuen Entwicklern deutlich erschwert ist "grunt". Vorher konnte man seine Änderungen sofort sehen. Dies war für mich auch ein riesen Vorteil der Cometvisu. Jetzt muss man zuerst alles "kompilieren". (Oder ist der dev-Sourcecode auch lauffähig ohne kompilieren? Dann wäre es nicht so tragisch).
Generelle Frage: bringt denn grunt so einen wesentlichen Performance-Gewinn?

Grunt wird nur für "Verwaltungsaufgaben" wie z.B. das Erstellen eines Releases, Ausführen von Tests usw. benutzt. Die CometVisu 0.10.0 kann man auch in der reinen Source-Version laufen lassen (wie bisher auch). Für 0.11.0 gilt das mit einer kleinen Einschränkung: man vor der ersten Benutzung einmal "git submodule init + git submodule update" ausführen und einmal "./generate.py source" um eine lauffähige source Version zu haben. Solange man danach in den vorhandenen Dateien Änderungen durchführt, kann man die wie gewohnt einfach ohne weitere Schritte nutzen. Nur wenn man eine neue Datei anlegt muss man noch einmal "./generate.py source" ausführen.

Abgesehen von den genannten Einschränkungen, kann man seine Änderungen also nach wie vor immer noch sofort sehen.

Da müssen wir aber sowieso noch ein Howto zu schreiben, wie man Plugins in der neuen Version anlegt.

Und zur zweiten Frage: Also der Build mit dem verkleinerten Javascript Source-Code ist schon schneller, für 0.11.0 ist der Unterschied noch deutlicher, also klar bringt das erstellen des Builds mit grunt einen Performance-Gewinn, aber zum Entwickeln braucht man das nicht.

[mfd]

Da es vom Titel her auch hier mit rein passt:
Wie sieht es mit der "next Generation CV" auf den "Next Generation" Wiregate-Geräten aus? Ist geplant diese wieder standardmäßig mitzuliefern?
Oder gibt es Bestrebungen die CV zukünftig (auch) mit anderen Systemen zu kombinieren?

[Chris M.]

Da es vom Titel her auch hier mit rein passt:
Wie sieht es mit der "next Generation CV" auf den "Next Generation" Wiregate-Geräten aus? Ist geplant diese wieder standardmäßig mitzuliefern?

Aus meiner Sicht: ja gerne. Aber Elaborated Networks entscheidet selber was und wie sie es unterstützen. Dennoch gehe ich davon aus, dass auch neue Versionen auf das WireGate kommen werden.

Oder gibt es Bestrebungen die CV zukünftig (auch) mit anderen Systemen zu kombinieren?

Auch hier: gerne. Wir arbeiten mit jedem zusammen, der das machen möchte.
Manche nutzen den Code direkter - wie eben das WireGate - und manche mit deutlich mehr Anpassungen - wie der JUNG Smart Visu Server.

[peuter]

Ich habe gerade den "develop" Branch altualisiert, dieser enthält nun die "Next Generation" CometVisu. Kleiner Hinweis für alle die die Änderungen pullen und testen möchten. Folgendes muss danach gemacht werden:

git submodule init
git submodule update
./generate.py source

Dann kann die Source Version genau so geladen werden wir früher (mit dem Unterschied, dass sie nun im Unterordner "source" und nicht mehr in "src" zu finden ist). Ebenfalls empfiehlt es sich mal einen einen Blick in die DEVELOPMENT.md zu werfen (https://github.com/CometVisu/CometVi...DEVELOPMENT.md)

Noch ein paar Links:
Source-Code Doku für Entwickler:
http://cometvisu.org/CometVisu/en/latest/api/

Handbuch:
http://cometvisu.org/CometVisu/de/latest/manual/

Nightly Builds:
https://bintray.com/peuter/CometVisu...ightlies#files

Nachdem die eine sehr tiefgreifende Änderung was, muss das ausgiebig getestet werden. Vor allem die Plugins sind z.T. ungetestet. Wir benötigen an dieser Stelle wirklich die Hilfe von der Community. Je mehr das testen desto besser.

Wer Fehler findet sollte sie nach dieser Anleitung melden:
http://cometvisu.org/CometVisu/de/la...icht-erstellen