Code Umstellung zur Performance-Optimierung

[Chris M.]

Hallo zusammen,

mit Revision 2343 habe ich einen ersten Commit zur Optimierung eingecheckt.

Hintergrund dieses Commits: Die Per-Widget JQuery .data() wurden aufgelöst und in eine zentrale Struktur (templateEngine.widgetData={}) überführt.
Ziel ist es, so eine Änderung des Codes zu ermöglichen, dass alle kleinen HTML-Parse-Abschnitte zu einem (oder wenigen) großen zusammengefasst werden können.

Da dieses Änderung ziemlich tief und verteilt ist, bitte die neue(n) Version(en) ausgiebig testen!

Was bekannt ist: infotrigger und multitrigger funktionieren aktuell nicht mehr.

[Fry]

Super, danke Chris! Teste ich gerne. Wird denn infotrigger bald "nachgereicht"? (brauche ich, im Gegensatz zu Multitrigger).
Vg, Fry

[Fry]

Die gute Nachricht: Es hat sich gefühlt beschleunigt. Messen werde ich später mal.

Die schlechte Nachricht: beim Seitenaufbau in groups und Layout ist sehr vieles leider vollkommen verkehrt. Mir erscheint es so, als wollte die Visu nun in jeder Gruppe 12 Spalten einrichten, auch wenn die Gruppe viel kleiner ist. Und die automatische Erweiterung der Gruppe auf die benötigte Zeilenzahl funktioniert auch nicht.

Habe auf rev 2341 reverted.

Gute Nacht
Fry

[Chris M.]

Wird denn infotrigger bald "nachgereicht"? (brauche ich, im Gegensatz zu Multitrigger).

Ja, beides. Die Änderung ist nur schon so groß geworden, da wollte ich ein dezentrales Backup. Und da fast alles schon wieder gehen sollte, war's ein guter Zeitpunkt das Testen starten zu lassen

Die gute Nachricht: Es hat sich gefühlt beschleunigt. Messen werde ich später mal.

Ich hab bei mir noch gar nicht gemessen. Wie schon geschrieben, erwarte ich mir von dieser Änderung keinen großen Sprung (ein kleiner ist durchaus möglich), das ist eigentlich nur vorbereitend.

Die schlechte Nachricht: beim Seitenaufbau in groups und Layout ist sehr vieles leider vollkommen verkehrt. Mir erscheint es so, als wollte die Visu nun in jeder Gruppe 12 Spalten einrichten, auch wenn die Gruppe viel kleiner ist. Und die automatische Erweiterung der Gruppe auf die benötigte Zeilenzahl funktioniert auch nicht.

Sehr gut. Genau das sind die Infos die ich mir vom Testen erwarte.
Die Demo-Config hat nämlich schon getan, die nutzt Columns aber nur bisschen.

Habe auf rev 2341 reverted.

Das war die Idee dahinter (wobei 2342 auch gegangen wäre. Aber vermutlich interessiert dich der Fix in der Demo-Config nicht )

[peuter]

Das Problem mit den columns in groups hab ich mal versucht zu fixen, ich denke es ist mit auch gelungen in #2344. Ich hoffe mal das ich das im Sinne des Erfinders korrekt programmiert habe ;-)

Gab auch noch ein kleines Problem (fehlendes +'_') im path der pages, was dazu geführt hat, das die Parameter showtopnavigation, showfooter, shownavbar nicht an der richtigen Stelle abgespeichert wurden und somit nicht funktioniert hatten.

[MicHau]

Die Demo-Config hat nämlich schon getan, die nutzt Columns aber nur bisschen.

Das war die Idee dahinter (wobei 2342 auch gegangen wäre. Aber vermutlich interessiert dich der Fix in der Demo-Config nicht )

Der Fix in der Demo-Config hat mich darauf gestoßen: Du verwendest da Page-Ids, das macht ja nur bedingt Sinn, denn da kann man auch den Pagenamen eintragen, dann klappt es immer, auch bei strukturellen Veränderungen. Leider sitze ich am falschen Rechner, um da selbst eine Korrektur herbeizuführen. Vielleicht korrigierst du es schon selbst.

Wenn nicht, kann ich eventuell morgen danach schauen.

[MicHau]

Gab auch noch ein kleines Problem (fehlendes +'_') im path der pages, was dazu geführt hat, das die Parameter showtopnavigation, showfooter, shownavbar nicht an der richtigen Stelle abgespeichert wurden und somit nicht funktioniert hatten.

Auch in der neuesten Version wird die Navigationszeile ganz oben eingeblendet, sobald ich auf eine Subpage (also nicht auf die Startseite) gehe. Irgendwie scheint die Vererbung des Parameters auf die Subpages noch nicht zu klappen.
Geändert hat sich außerdem, dass bei mir die linke Navigationsleiste plötzlich weniger Platz in Anspruch nimmt als vorher, der content-Bereich aber nicht von rechts dran geschoben wird, sprich es gibt eine Lücke dazwischen.

[Chris M.]

Der Fix in der Demo-Config hat mich darauf gestoßen: Du verwendest da Page-Ids, das macht ja nur bedingt Sinn, denn da kann man auch den Pagenamen eintragen, dann klappt es immer, auch bei strukturellen Veränderungen. Leider sitze ich am falschen Rechner, um da selbst eine Korrektur herbeizuführen. Vielleicht korrigierst du es schon selbst.

Da hast Du recht. Hab's gerade mal gefixt und eingecheckt.

(Unter uns: wir haben bei der Navigation über Namen allerdings noch eine Schwachstelle. Beim Pagejump mag es notfalls akzeptabel sein, aber bei den Sub-Pages selbst beißt es uns: Haben mehrere Sub-Pages den gleichen Namen, wird immer die erste angesprungen - Test: Demo-Config -> Flavour Test -> Flavour: Antimony -> Subpage ==> wir kommen bei Flavour Whire raus )

[Chris M.]

Mit #2348 sollte jetzt auch infotrigger und multitrigger wieder gehen.

[Chris M.]

Ich hoffe mal das ich das im Sinne des Erfinders korrekt programmiert habe ;-)

Ich weiß nicht welchen Erfinder Du gemeint hast, falls mich: ja hat gepasst - auch wenn ich eine Kleinigkeit davon im aktuellen Patch (2350) wieder zurück genommen habe um etwas anderes zu fixen.

$.data() sehe ich nicht pauschal als verboten an, ich möchte das nur aus der Widget-Generierung heraushalten um (Fernziel) alle Widgets am Ende nur in einen einzigen String zu schreiben der genau 1x an innerHTML übergeben wird. Dadurch hoffe ich Performance zu holen die durch wiederholte Aufrufe von Parse HTML verloren geht. Dazu kann ich aber an kein Element da drinnen etwas per $.data() anhängen. (Lassen wir mal die data- Attribute weg, denn ich hab ja eh schon an jedem Widget eine ID die das ganze wunderbar ersetzen kann...)

Auch in der neuesten Version wird die Navigationszeile ganz oben eingeblendet, sobald ich auf eine Subpage (also nicht auf die Startseite) gehe.

Ja, ist mir bei der metal-Demo auch aufgefallen. Muss noch behoben werden.

Geändert hat sich außerdem, dass bei mir die linke Navigationsleiste plötzlich weniger Platz in Anspruch nimmt als vorher, der content-Bereich aber nicht von rechts dran geschoben wird, sprich es gibt eine Lücke dazwischen.

Schau mal, ob's jetzt besser ist.
Die column-Einstellungen der Navbars hatte vorher nicht funktioniert, das ist jetzt mit 2350 behoben.

[peuter]

Ja, ist mir bei der metal-Demo auch aufgefallen. Muss noch behoben werden.

Sollte mit 2351 erledigt sein.

Mit 2352 habe ich versucht das Problem mit den Pagejumps auf die mehrfach vorhandenen Subpages zu lösen. Sobald es mehrere Seiten mit dem gleichen Namen gibt, werden die bevorzugt, die entweder Übergeordnete oder Unterseiten der aktuell geöffneten Seite sind.

Das behebt das Problem in der Demo. Aber sollte man mehrere Seiten mit gleichem Namen innerhalb eines "Seiten-Asts" haben bleibt das Problem weiterhin bestehen. Ist also keine komplette Lösung des Problems, aber es wird reduziert auf einen Sonderfall.

[Chris M.]

Ich versuche aktuell unter https://github.com/ChristianMayer/CometVisu mit dem Code-Umbau weiter zu machen.

Hab auch schon den nächsten Schritt eingecheckt, aber auf GitHub erscheint der noch nicht...

[Dirk42]

Hmmm... auf "Wechsel der Entwicklungsplattform" hast Du geschrieben, dass die Adresse https://github.com/CometVisu/CometVisu ist. Arbeitest Du tatsächlich grade mit zwei verschiedenen Repositories...?

[Chris M.]

Nun, ich habe irgendwo gelesen, dass man bei Git ganz oft Forken soll...

Daher versuche ich mich gerade daran, hier was im Fork weiter zu entwickeln (der unter meinem Namen läuft) und dass dann per Pull wieder hochzuschieben.

Mit dem ersten Commit scheint das nun auch geklappt zu haben (hab aber nur halb verstanden was ich da gemacht habe, bzw. machen musste; naja, ich lerne ja noch.)

=> Zum Testen und Mitmache hätte ich vorgeschlagen diesen Fork zu nehmen - oder macht man das eigentlich anders?

[peuter]

=> Zum Testen und Mitmache hätte ich vorgeschlagen diesen Fork zu nehmen - oder macht man das eigentlich anders?

Ich kenne das (von openHAB) so, dass jeder der etwas zum Code beisteuern möchte einen eigenen Fork macht dort seine Änderungen drin macht und wenns reif für das Haupt-Repository ist wird ein Pull-Request erstellt: Hab das zur Übung gleich mal gemacht: Die rowspans haben nämlich nicht funktioniert.

Im Grunde macht damit jeder dasselbe, wie Du im Moment. Nur das Du eben auch selbst ins Haupt-Repo mergen kannst.

Aber hier gibts sicherlich Leute die mehr Ahnung von Github haben, ich bin da immer noch Anfänger. Vielleicht gibts da auch einen anderen/besseren Weg.