Entwickler Unterstützung gesucht - Release-Vorbereitung

[kleinklausi]

Der alte Editor der Releas hatte da absolut Potential intuitiv zu sein..

Schön finde ich Deine Überlegungen! Nur hat sich bisher halt keiner gefunden, der bereit ist das zu implementieren.

Ich bin einfach nur froh, dass sich jemand dem Editor angenommen hat und wir damit in absehbarer Zeit ein neues Release hinbekommen.

Gruß Moritz

[swiss]

Klar... Ich bin auch froh, dass sich sich jemand um den Editor und desssen Weiterentwicklung kümmert. Ich habe auch nur laut nachgedacht. Denn der Editor ist zwar für die Entwickler nun viel pflegeleichter aber dafür so ziemlich 100% wehniger intuitiv zu bedienen als der Vorgänger. Beim neuen Konzept muss man sich schon sehr mit XML, HTML und CSS befasst haben um eine hübsche Visu hin zu bekommen. Ich will ja nicht lästern und die tolle Arbeit von Julian schlecht machen (er leistet wirklich tolle Arbeit ohne die ein Releas in weiter ferne wäre ) aber mir hat der alte Editor besser gefallen... Er war halt intuitiver zu bedienen.

Hier stehen 20 Cracks die wirklich Ahnung haben und die tollsten Sachen machen gegenüber >200 Nutzer die nicht viel Ahnung haben, die CV aber auch ohne 100 Seiten Handbuch zu lesen, hübsch gestalten möchten... (da werden sie aber momentan nicht herum kommen. Ich wette, dazu werden nach dem Releas innert kürzester Zeit einige Forenfragen kommen weil die Leute überfordert sind... )

Es geht ja auch nicht darum heute oder Morgen den Editor wieder eher "nutzerfreundlicher" zu machen. Aber längerfristig müsste man sich da wirklich nochmal darüber gedanken machen...

Ich hoffe ich bin damit niemandem zu neahe getreten. Ich kann selber leider 0 dazu beitragen da ich weder JS, PHP, Ajax noch sonst eine nützliche Programmiersprache behersche die hier hilfreich wäre. Aber ich bin der Mienung, dass man darüber zumindest ab und zu wieder mal laut nachdenken darf, in der Hoffnung, dass die CV nicht zu einer totalen Freekshow (aus sicht der einfachen Nutzer) wird.

[Chris M.]

Da schon viel richtiges steht, will ich es nicht wiederholen.

Zum Thema Handbuch: Ich lese auch keine. (Ich bin aber auch kein typischer User-Vertreter...)

Was ich dagegen oft lese: eine Referenz.
Genau das ist das aktuelle Handbuch - und die ist nicht nur für Handbuch-Verweigerer wie mich wichtig, sondern für jeden der selber laufen können möchte.

Was ich manchmal lese, insb. am Anfang um einen Überblick zu bekommen - und ich denke auch für jeden Einsteiger wahnsinnig wichtig ist: ein Tutorial.

Also ein Dokument, das einen Schritt für Schritt an die Hand nimmt, bis das grundsätzliche Gerüst steht (und man so einmal alle Konzepte gesehen hat) und von dem man dann selber weiter machen kann.
=> Für mich fehlt das Tutorial noch.

Das kann auch jeder Erstellen, der nicht programmieren kann. Im Gegenteil, ein "außenstehender" kann das sogar deutlich besser als jemand der die Internas kennt, der nimmt nämlich zu viel als selbstverständlich an. Daher sind die besten HowTo-Schreiber die, die sich gerade durchkämpfen...

[makki]

..
Denn der Editor ist zwar für die Entwickler nun viel pflegeleichter aber dafür so ziemlich 100% weniger intuitiv zu bedienen als der Vorgänger.
..

Ganz klar, jetzt aber mal klartext: ich bin daran - nach vielen Abstimmungen, überlegungen etc. wenigstens 100% "mitschuldig" - der alte war so mit vertretbarem Aufwand einfach nicht pflegbar.
Es gibt dazu jedoch schon einen Plan (den Editor sollen am Ende des Tages nur die "Checker" brauchen/nutzen "müssen"!)
Denn ich will auf was ganz anders hinaus

...
Das kann auch jeder Erstellen, der nicht programmieren kann. Im Gegenteil, ein "außenstehender" kann das sogar deutlich besser als jemand der die Internas kennt, der nimmt nämlich zu viel als selbstverständlich an. Daher sind die besten HowTo-Schreiber die, die sich gerade durchkämpfen...

Absolut! Ich bin unfähig die eigene Online-Hilfe zu schreiben, weil man einfach zuviel weiss und damit die hälfte an wichtigen Infos vergisst..

Makki

[Bodo]

look who's talking (auf mich bezogen)

Absolut! Ich bin unfähig die eigene Online-Hilfe zu schreiben, weil man einfach zuviel weiss und damit die hälfte an wichtigen Infos vergisst..
Makki

Hoi

Ach alles Ausreden...

[daviid]

Full ACK Makki.

Ich kenn das auch, früher als ich noch deutlich mehr gecodet hab (vor allem PHP und manchmal auch JS fürn CMS), da wird man auch seeeehr schnell Betriebsblind, aber ab und zu bekomm ich immer so nen "ich stell mich auf "Dumm" Schub", da kann ich warum auch immer irgendwie auch den normalen User verstehen.

Ist wirklich ne Gradwanderung das Ganze.

Was auf jeden Fall noch fehlt ist teilweise die Doku, da werd ich auch mal versuchen wieder dran mitzuarbeiten wenn ich Zeit find.

Beispiel: Mir gefiel beim diagram_info nich wo die Legende dargestellt wird, also wollt ich das quick and dirty in der CSS ändern, bin dann aber durch Zufall in der XSD drauf gestoßen dass es dafür auch schon nen Attribut gibt.

Das könnt ich mir mal vornehmen, wenns nichts wird mich bitte dran erinnern, ich vergess sowas SEHR schnell ...


Zum Editor, klar der alte war wirklich intuitiv, aber auch aufwändig, aber schon da hab ich einfach nurnoch im XML geschafft, genau wie heute, ich komm da einfach VIEL schneller zum Ziel.
Ich kann mir eig auch immer schon im XML-Vorstellen wie das nacher aussieht, kommt wohl daher dass ich auch schon viel mit CSS und HTML gemacht hab, auch wenn das meiste inzwischen wieder vergessen ist, aber auffrischen geht ja immernoch ...

[swiss]

Es ist wirklich eine schwirige Gratwanderung. Der autogenerator an den makki denkt gehöhrt für mich in die QC ecke. Da bekommen einfach alle die gleiche Visu nach Schema F... -> minimaler aufwand aber auch minimal individuell

Das was XML und der aktuelle Editor bieten ist die maximale Flexiblität auf kosten von 100% intuitivität. -> Ist also für alle die nix mit den Internas von HTML, CSS und XML am Hut haben ien Graus

Dass an das ich denke sollte ein Mittelweg sein. Ein Editor den manin der Handhabung sehr schnell beherscht ohne sich mit irgend welchen Programmiertechnischen begebenheiten befassen zu müssen. Also klicki bunti mit drag&drop, coppy&paste und alles wie man es sonnst auch von der normalen Benutzung des Computers kennt. Dass bedarf praktisch 0 Erklärug für unerfahrene und bietet doch viel mehr gestalterische Freiheitals ein Visugenerator der eine Schema F Visu aus dem Hut zaubert. -> Dass wäre ein echtes Alleinstellungsmerkmal für die CV denn die meisten Visus sind entweder nur minimal flexibel (z.B. QC oder ProServ) oder benötigen einen Docktortitel in Programmierung und sehr viel Zeit... So unter dem Motto "Nur von Programmierer für Programmierer"

Dass die Umsetzung und Pflege nicht leicht ist, ist mir klar. Und es würde vermutlich auch schwierig werden jemanden zu finden, der dass in die Hand nehmen würde. Aber ganz ehrlich... In sachen Benutzerfreuntlichkeit für reine Anwender die schon mit der ETS an ihre Grenzen stossen, ist der neue Editor ein echter Rückschritt Aber ich bin guter Dinge, dass sich da in punkto "Benutzerfreundlichkeit" irgend wann noch was tun wird

[peuter]

Auf einen (weichen) Feature Freeze(*) können wir uns wohl einigen, die aktuelle Version hat ja schon sehr viele Neuigkeiten, wie das ChangeLog weiß:

Ich habe gestern mal versucht das initiale Abfragen der Stati zu verbessern.
Das bisherige vorgehen ist ja so:

1. Status-Abfrage aller GA's
2. Horche auf Status-Änderungen aller GA's mittels Long-Polling

Die neue Variante macht folgendes:

1. Status-Abfrage aller GA's auf der Startseite
2. Status-Abfrage aller anderen GA's
3. Horche auf Status-Änderungen aller GA's mittels Long-Polling

Die Änderungen, die ich dafür am Code gemacht habe sind relativ einfach und lokal auf die cometvisu-client.js beschränkt. Ebenfalls ist die neue Variante nur über einen extra URL-Parameter aktivierbar, fehlt dieser bleibt alles beim alten. Da dies aber eine sehr zentrale Funktion der Visu ändert, weiß ich nicht so recht ob dies noch als erlaubte Änderung in einem weichen Feature-Freeze durchgeht.
Daher wollte ich das erstmal hier klären bevor ichs einchecke.


Ich habe leider nicht genug Adressen in meine Config, um einen spürbaren Performancegewinn zu sehen, gefühlt ists zwar schneller (zumindest auf dem Handy) kann aber auch ein wenig Wunschdenken/Einbildung sein .

Ums das ganze Thema richtig anzugehen müsste man eine zentrale Komponente implementieren, die alles "nachladbare" kümmert und somit Stati,Diagramme,Bilder usw. anhand definierter Prioritäten nacheinander lädt. Das wäre dann ein TODO nach dem nächsten Release, gibt auch schon als Feature-Request von Makki, glaube ich.

[Chris M.]

Ich habe gestern mal versucht das initiale Abfragen der Stati zu verbessern.
[...]
Die neue Variante macht folgendes:

1. Status-Abfrage aller GA's auf der Startseite
2. Status-Abfrage aller anderen GA's
3. Horche auf Status-Änderungen aller GA's mittels Long-Polling

Erst mal klingt das vernünftig.

Die Änderungen, die ich dafür am Code gemacht habe sind relativ einfach und lokal auf die cometvisu-client.js beschränkt.

Diese Datei bzw. Bibliothek ist extrem zentral und wird nicht nur von der CometVisu verwendet, die man hier unter diesem Namen versteht. (Vgl. CometVisu/Overview - Open Automation - hier werden die meisten unter dem Namen "CometVisu" die "CometVisu Visualisation" verstehen - es gibt aber auch andere Anwendungen, die das CometVisu Protokoll und den CometVisu Client nutzen. Und cometvisu-client.js ist eben der CometVisu Client)

Ebenfalls ist die neue Variante nur über einen extra URL-Parameter aktivierbar, fehlt dieser bleibt alles beim alten. Da dies aber eine sehr zentrale Funktion der Visu ändert, weiß ich nicht so recht ob dies noch als erlaubte Änderung in einem weichen Feature-Freeze durchgeht.

Ich denke, das hängt ganz von der Änderung ab. D.h. hier würde ich ein Peer Review bzgl. Nebenwirkungsfreiheit vorschlagen.
Wenn die Änderungen klein und übersichtlich sind ist's was anderes als bei tiefgreifenden Änderungen.

Ich habe leider nicht genug Adressen in meine Config, um einen spürbaren Performancegewinn zu sehen, gefühlt ists zwar schneller (zumindest auf dem Handy) kann aber auch ein wenig Wunschdenken/Einbildung sein .

Das frage ich mich nämlich auch - bringt es viel?
Die initiale Abfrage liest alles, was im Cache ist, d.h. die wird sofort beantwortet. Durch diesen Trick kann man höchstens die übertragene Datenmenge reduzieren, die zum Ausfüllen der Widgets empfangen wird.
Das Anzeigen der Widgets an sich ist davon unabhängig.

Ums das ganze Thema richtig anzugehen müsste man eine zentrale Komponente implementieren, die alles "nachladbare" kümmert und somit Stati,Diagramme,Bilder usw. anhand definierter Prioritäten nacheinander lädt. Das wäre dann ein TODO nach dem nächsten Release, gibt auch schon als Feature-Request von Makki, glaube ich.

Ja, wäre sinnvoll aber für mich auch erst nach dem nächsten Release.

Genau so gibt es ja im CometVisu Protokoll schon die Möglichkeit die Datenübertragung zu reduzieren: Filter.
Die sind aber z.Zt. weder im Backend noch im Client implementiert. Das wollte ich erst mit dem neuen Backend angehen, denn dann muss das Backend einen Status pro Client speichern, was aktuell noch nicht der Fall ist. Ein simples CGI-BIN wie aktuell reicht dann nicht mehr...

[peuter]

Ich denke, das hängt ganz von der Änderung ab. D.h. hier würde ich ein Peer Review bzgl. Nebenwirkungsfreiheit vorschlagen.

Ich weiß zwar nicht genau, was das bedeutet, aber der Patch liegt bei und somit kann das jeder vorab testen. Um das neue Verhalten zu aktivieren muss man ?enableQueue=1 an die URL dranhängen.

Das frage ich mich nämlich auch - bringt es viel?
Die initiale Abfrage liest alles, was im Cache ist, d.h. die wird sofort beantwortet. Durch diesen Trick kann man höchstens die übertragene Datenmenge reduzieren, die zum Ausfüllen der Widgets empfangen wird.
Das Anzeigen der Widgets an sich ist davon unabhängig.

Das Ganze zielt für mich eher auf besonders schwachbrüstige Clients, bei denen es spürbar schneller sein könnte 10 anstatt 200 Status-Updates zu verarbeiten. An der Stelle erhoffe ich mir einen Performance-Gewinn.

[Chris M.]

Ne, also so geht der Patch sicher nicht:

• Er geht davon aus, dass wir hier GAs haben - das ist dem CometVisu-Protokoll und CometVisu-Client aber vollkommen egal. Die wissen von KNX nichts und soll es auch nie wissen. Wir könnte ja auch xPL, OPC UA oder gar CPU Register übertragen...
• Es wird auf die DOM-Struktur zugegriffen - es wird also vorgeschrieben, wie die CometVisu-Visualisierung auszusehen hat. Das kann bereits mit einer anderen Struktur (aktuell haben wir nur "pure", könnte aber z.B. ja mal eine jQuery-Mobile dazu kommen...) fürchterlich auf die Schnautze fallen. Und andere Anwendungen, die das CometVisu-Protokoll nutzen (z.B. der PyWireGate-Logik-Editor) sind gleich vollkommen ausgeschlossen.

Wenn, dann muss das ganz anders aufgebaut sein:

• Eine CometVisu-Client API Funktion, die eine alternative Liste von Adressen bekommt und nach dem Empfangen dieser Daten die vollständige Liste lädt, danach dann differentiell wie gehabt.
  (Es muss das zweite mal die volle Liste sein, da sich zwischenzeitlich ein Status geändert haben könnte).
• Die restliche Funktionalität in der CometVisu-Visualisierung (also vermutlich templateengine.js)

[peuter]

• Er geht davon aus, dass wir hier GAs haben - das ist dem CometVisu-Protokoll und CometVisu-Client aber vollkommen egal. Die wissen von KNX nichts und soll es auch nie wissen. Wir könnte ja auch xPL, OPC UA oder gar CPU Register übertragen...

Das sehe ich anders: Es wird auf die Daten, die beim Actor als address gespeichert werden zugegriffen. Ob das nun eine GA oder sonstwas ist, ist egal.

• Es wird auf die DOM-Struktur zugegriffen - es wird also vorgeschrieben, wie die CometVisu-Visualisierung auszusehen hat. Das kann bereits mit einer anderen Struktur (aktuell haben wir nur "pure", könnte aber z.B. ja mal eine jQuery-Mobile dazu kommen...) fürchterlich auf die Schnautze fallen. Und andere Anwendungen, die das CometVisu-Protokoll nutzen (z.B. der PyWireGate-Logik-Editor) sind gleich vollkommen ausgeschlossen

Für andere Anwendungen ist dieser Code ja auch nicht gedacht, aber folgerichtig hat der dann in der cometvisu-client.js nichts zu suchen. Dementsprechend habe ich die spezifischen Teile in die Templateengine verschoben.

• Eine CometVisu-Client API Funktion, die eine alternative Liste von Adressen bekommt und nach dem Empfangen dieser Daten die vollständige Liste lädt, danach dann differentiell wie gehabt.
  (Es muss das zweite mal die volle Liste sein, da sich zwischenzeitlich ein Status geändert haben könnte).

Sehe ich ein und habe das entsprechend geändert, siehe neuer Patch. Über CometVisu.setInitialAddresses() kann eine alternative Liste mit Adressen übergeben werden, die, sofern nicht leer, vorab geladen wird.

• Die restliche Funktionalität in der CometVisu-Visualisierung (also vermutlich templateengine.js)

Done. Ich denke so ist die Lösung auf jedenfall sauberer. Leider haben mir im Vorfeld doch einige Zusammenhänge gefehlt, sonst hätte ichs gleich ein wenig sauberer gelöst. Man lernt nie aus

[makki]

Hmm, habs jetzt nicht 100% durchgetestet aber sieht schlüssig aus - bringt aber nicht mehr als 100ms weil der eibd pumpt auch 1000 GA's in 50ms ausm Cache raus

Das viel grössere Problem/Delay bei Start sind Grafiken (image, diagram), dafür ist IMHO noch dringend eine Lösung (queue, delay, was-auch-immer) zu finden.

Makki

[netzkind]

[..]bringt aber nicht mehr als 100ms weil der eibd pumpt auch 1000 GA's in 50ms ausm Cache raus [..]

Ich halte die Idee von Tobias für sinnvoll, und zwar weil ich folgende zwei Punkte noch sehe:
1) Bearbeitungszeit auf JS-Seite, um die Informationen zu verarbeiten, per jQuery die passenden Elemente auf der Seite zu suchen, und deren Updates anzutriggern
2) langsame Verbindungen, wenn man bspw. per VPN vom Smartphone aus "arbeitet"

Kosten/Nutzen habe ich nicht abgewägt, und den Code nicht angeschaut - die Meinung von mir ist also erst mal rein theoretischc

[Chris M.]

Done. Ich denke so ist die Lösung auf jedenfall sauberer.

Ja, so sieht's deutlich besser aus!

Warum hast Du diesen Code entfernt?

    var obj={};
    for (var i=0;i<addresses.length;i++) {
      obj[addresses[i]]=0;
    }
    for (var i in obj) {
      this.addresses.push(i);
    }

Der soll verhindern, dass eine Adresse gleich mehrfach angefordert wird...

Leider haben mir im Vorfeld doch einige Zusammenhänge gefehlt, sonst hätte ichs gleich ein wenig sauberer gelöst.

Das liegt in der Natur der Sache. Manches ist nur gewachsen und müsste längst ausgemistet werden - aber man traut sich nicht dran, weil es muss ja was komplexes lösen weil man's nicht versteht (warum wäre sonst der Code so komplex )
Anderes sieht erst mal unschuldig aus - da steckt aber viel dahinter das man leicht zerstören kann.

Im "normalen Leben" klärt man das kurz beim Kaffee.
Hier in der virtuellen Zusammenarbeit geht das leider nicht so leicht.

Wenn man sich das einfach mal bewusst macht, wird alles noch entspannter

PS: Wir können gerne ICQ# austauschen für die Fragen nebenbei.