CometVisu - (interner) Beta-Test

[netzkind]

Hi Chris,

so, ich hab jetzt auch mal daheim ein svn update machen können.
Feedback dazu:

• Das Design ist nun in der normalen Config-XML einstellbar

Bin ich nach einem Test bei mir nicht so ein Freund von - zumindest in der aktuellen Umsetzung per Javascript in setup_page(): Die Visu wird dadurch erst mal wie eine 404-Seite komplett ohne Stylesheets dargestellt, und erst wenn das XML geladen wurde fängt der Browser an das CSS zu laden. Dadurch hab ich mindestens ein paar wenige Sekunden lang eine Darstellung die unreif wirkt.

Beispielsweise eine Idee wäre, dass wir statt der index.html eine index.php verwenden, die als einzigen Mehrwert das XML liest um zu ermitteln welches Design benötigt wird, und das CSS vor der Auslieferung an den Browser fest im HTML verankert.
Dadurch würden wir uns sparen einen unschönen ersten Eindruck zu hinterlassen.

Performance auf dem Server wäre kein Problem, da es nur zum Ladezeitpunkt geschieht (gerne dann auch cached per mtime auf die xml).

Wie siehst du das, Chris?

Grüße,
Julian

[netzkind]

Hi makki,

Widgets: mal angenommen man schreibt sich jetzt ein Widget das jQuery-addon xy braucht. Und dann noch eins usw..
Würde es evtl. Sinn machen (strukturell) vorzusehen, das js-Addons nur für verwendete Widgets geladen werden? Oder ist das eher vernachlässigbar?

Ich finde, dass jedes widget welches zusätzliche Dateien braucht das innerhalb der create-Methode selbst tun sollte. Wer so weit ist dass er soetwas umsetzt weiß dann auch zu verhindern dass die Datei mehrfach eingebunden wird.

In dem Zusammenhang:
ich würde vorschlagen die visudesign_custom.js aus dem lib/-Ordner raus in einen eigenen Ordner zu packen, gerne auch die Config-XML dann in den Ordner - damit User-modified-content gleich von der Ordnerstruktur an einem anderen Ort liegt.

Grüße,
Julian

[netzkind]

Wenn ich das richtig verstehe, spinnt jQuery bei einem style-Attribut in einer XML-Datei?!?

Dann ist meine Meinung, dass jQuery da einen Bug hat...

Es handelt sich dabei nicht um XML-Elemente, sondern um in Javascript erzeugte Objekte die dann per jQuery verarbeitet werden als wären sie normale DOM-Elemente.

Soweit ich den Quellcode von jQuery verstanden habe: Da krachts, weil jQuery aus Performance-Gründen auf das Attribut "style" nicht selbst zugreift, sondern anhand von Browser-Funktionen - und das funktioniert nur bei DOM-Elementen. Deshalb: peng.

Klar. Das kostet uns nämlich nichts (an Laufzeit). Nur über den neuen Namen bin ich mir noch nicht klar. "Design" finde ich schlecht (genau so wie "Flavour"), da es zu Verwirrungen mit dem Visu-Design kommen kann, da dort diese Namen schon besetzt sind.

Muss da nochmal nachdenken, oder gibt's hier inspirierende Vorschläge?

Nicht ganz einfach. Da es sich im Endeffekt bei der Nutzung mit visudesign_pure um die Zuweisung einer CSS-Klasse handelt, fallen mir "styleclass" oder "class" ein, oder einfach "stylegroup", eventuell auch "styling" - passend zu "mapping" welches ja auch nicht "map" heißt.

Grüße,
Julian

[Chris M.]

Bin ich nach einem Test bei mir nicht so ein Freund von - zumindest in der aktuellen Umsetzung per Javascript in setup_page(): Die Visu wird dadurch erst mal wie eine 404-Seite komplett ohne Stylesheets dargestellt, und erst wenn das XML geladen wurde fängt der Browser an das CSS zu laden. Dadurch hab ich mindestens ein paar wenige Sekunden lang eine Darstellung die unreif wirkt.

Beispielsweise eine Idee wäre, dass wir statt der index.html eine index.php verwenden, [...]

Momentan sieht es tatsächlich kurz suboptimal aus.

Die Lösung mit der PHP würde ich aber nicht favorisieren wollen, da ich immer noch Minimal-Server wie eine Fritz!Box im Hinterkopf habe.

Die richtige Lösung (hatte ich schon versucht, aber nicht auf die Schnelle geschafft) ist IMHO, erst mal gar nichts anzuzeigen (z.B. per display:none) und erst mit dem Stylesheet die Darstellung wieder zu aktivieren.
Das Stylesheet wird übrigens schon jetzt geladen, bevor der dynamische Inhalt eingebaut wird.

[Chris M.]

ich würde vorschlagen die visudesign_custom.js aus dem lib/-Ordner raus in einen eigenen Ordner zu packen, gerne auch die Config-XML dann in den Ordner - damit User-modified-content gleich von der Ordnerstruktur an einem anderen Ort liegt.

Ja, bei dem Aufräumen war ich etwas großzügig.

Die visudesign_pure.js ist ja auch Design-bestimmend und gehört eigentlich nicht zu den allgemeinen Libs...

[NilsS]

Die richtige Lösung (hatte ich schon versucht, aber nicht auf die Schnelle geschafft) ist IMHO, erst mal gar nichts anzuzeigen (z.B. per display:none) und erst mit dem Stylesheet die Darstellung wieder zu aktivieren.
Das Stylesheet wird übrigens schon jetzt geladen, bevor der dynamische Inhalt eingebaut wird.

ACK ich denke auch das das der bessere Weg ist

[netzkind]

Die visudesign_pure.js ist ja auch Design-bestimmend und gehört eigentlich nicht zu den allgemeinen Libs...

Ich finde aber nicht dass sie in das Verzeichnis des users-contents gehört - meine gedankliche Trennung war "bei neuem Package Verzeichnis-Inhalt überbügeln ohne Reuegefühle" (macht auch Support leichter). Wer an der visudesign_pure rumschraubt hat das Prinzip von visudesign_custom noch nicht verinnerlicht

Grüße,
Julian

[Chris M.]

Nicht ganz einfach. Da es sich im Endeffekt bei der Nutzung mit visudesign_pure um die Zuweisung einer CSS-Klasse handelt, fallen mir "styleclass" oder "class" ein, oder einfach "stylegroup", eventuell auch "styling" - passend zu "mapping" welches ja auch nicht "map" heißt.

styling ist gut - gekauft!

[netzkind]

styling ist gut - gekauft!

Dann setz ich das mal grade um - hab eh noch ein paar Dinge fürs SVN hier liegen (nichts weltbewegendes, leider).

[netzkind]

Im SVN heißt es jetzt schon stylings.

Das schwere Los der Beta-Tester lautet dann - sobald das neue package erstellt wird oder man sich den source aus dem SVN holt: die eigene XML anpassen, dort alle Vorkommen von style umbenennen nach styling (und styles nach stylings).

Die Doku und das xsd sind angepasst, das Changelog enthält einen entsprechenden Eintrag.

Ich hab bei der Gelegenheit noch die Bugs aus dem Tracker gefixt, und den datatypes ein Dropdown spendiert. Alles in SVN-Revision 140.

Grüße,
Julian

[netzkind]

Achso, Thema dpt:
ich hab mir das PDF aus dem Lexikon-Eintrag hergenommen, und alle DPT_ID und DPT_NAME daraus kopiert um die Select-Liste erzeugen zu können.
Mir stellt sich da grade noch sicherheitshalber die Frage der Nutzungsrechte - da es sich um eine Formatbeschreibung handelt würde ich annehmen dass es im Interesse der konnex ist dass es so verwendet wird. Das PDF gibt leider keinen Aufschluss über mögliche Nutzungsrechte die eingeräumt werden.

Hat da jemand mehr Infos, und/oder Gewissheit?

Grüße,
Julian

[Chris M.]

[...]
Ich hab bei der Gelegenheit noch die Bugs aus dem Tracker gefixt, und den datatypes ein Dropdown spendiert. Alles in SVN-Revision 140.

Super!

Achso, Thema dpt:
[...]Mir stellt sich da grade noch sicherheitshalber die Frage der Nutzungsrechte [...]
Hat da jemand mehr Infos, und/oder Gewissheit?

1. Ich bin kein Anwalt
2. wir sind hier ja quasi offizielle KNX Entwickler (per Konstrukt über den Member ElaboratedNetworks). Und wenn wir da Infos in eine Computerverdauiche Form bringen müssen, dass unser Produkt mit dem KNX funktioniert, dann ist das halt so. Das ist normale Entwicklung. Wir veröffentlichen hier ja nicht eine bildliche 1:1 Kopie aus dem Standard (das wäre vom Copyright schwieriger - doch das würde ich dann als Zitat sehen...)

[Chris M.]

Ich finde aber nicht dass sie in das Verzeichnis des users-contents gehört - meine gedankliche Trennung war "bei neuem Package Verzeichnis-Inhalt überbügeln ohne Reuegefühle" (macht auch Support leichter). Wer an der visudesign_pure rumschraubt hat das Prinzip von visudesign_custom noch nicht verinnerlicht

Hab das jetzt mal in das Designs-Verzeichnis verschoben - und gleich passend umbenannt (da ich das neulich "Gerüst" genannt hatte, heißt's jetzt halt Structure)

D.h. das Lib-Verzeichnis ist jetzt ganz sauber nur mit Libs gefüllt.
Ob die structure_custom.js in's designs oder in's Hauptverzeichnis gehört, bin ich mir gerade noch etwas unsicher. Wie ist da Euere Meinung zu?

[makki]

@Julian: ich sehe da garkein Problem,
a) nicht allgemein (nur ElabNET vertreibt das ganze kommerziell, damit überhaupt "angreifbar" und ja nun - u.a. deswegen - KNX Member)

b) wie Chris schon schrieb: ihr entwickelt ja quasi "für uns" wenn man das so nennt, dafür darf,kann&will ich euch mit jeglichen relevanten Informationen - auch aus den "Geheimpapieren" - versorgen.
-> die zwar nicht weitergegeben, aber sehr wohl verwendet werden dürfen; auch zur Umsetzung in OSS;
ich hab mir diesen Teil in den unterschrieben Papers ziemlich aufmerksam & mehrmals durchgelesen

c) im speziellen: die komplette DPT-Beschreibung ist auch bei der Konnex selbst öffentlich runterladbar, also eh public


Zu den Verzeichnissen hab ich jetzt erstmal garkeine Meinung Denke das ist eher eine Frage der Entwicklungsseite, denn wer hier aktuell "custom" macht, steckt ja eh knietief im Code; irgendwann denkbar das man eben temporär zum entwickeln lokale Erweiterungen hat aber die sollen ja dann auch zügig ins upstream einfliessen.

Makki

[makki]

Die Demo-Visu ist auf svn-Stand.
Eine Sache: Beim laden kommt hier jetzt ein alert Error: "error": Mein Name ist Hase

Die toogle RGB habe ich vorerst rausgenommen, weil das sieht schlechter aus als es ist, da das DALI-GW ewig für die Statusrückmeldungen braucht..


Nebenbei: ich hab den Relaxx auch mal (mit fake-backend) online gestellt, IMHO ne rattenscharfe Sache..
Warum ich das hier schreibe:
Ob/Wie/falls könnte man sowas in die CometVisu integrieren?

Bisher mache ich das mit ario&Festerwechsel bzw. Browser-tabs, ziemlich unsmart..
(Fragen hierzu: Relaxx, mpd -> bitte neuer Thread!)

Makki