CometVisu - (interner) Beta-Test

[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]

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

[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

[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...

[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.

[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

[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]

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

[Chris M.]

Andere zwischenfragen:
1) reconnect (nach suspend. netzwerkfehler, whatever) - ist das eigentlich schon supposed to work? (vermute nein)

Nein, das geht noch nicht - ist aber wichtig (nur ist die Verbindung so stabil, dass ich da noch keinen Druck verspürt habe... Momentan sollte ein Reload auch die Verbindung wieder starten...)
Hab's aber mal in den Bugtracker geschrieben.

2) 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?

Gute und schwierige Frage. V.a. wenn man an Ressourcen limitierte Clients, wie Smartphones, denkt.

Ziel sollte immer sein, so wenig Libs wie nötig einzubinden. Und bei den bestehenden können wir sicher auch noch Funktionsumfang reduzieren.
Aber das sehe ich aktuell noch nicht als notwendige Aufgabe. Das kommt irgendwann zwischen öffentlichem Beta und final Release.

[NilsS]

2) 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?

Dazu würd ich empfehlen den Widgets IDs zu geben, und sie hierarchisch als Objekte anzulegen, war in der xxAPI auch so gedacht, hat nur nie jemand widgets erstellt Da könnte man aber einfach die Verfügbarkeit eines solchen testen.

[makki]

Andere zwischenfragen:
1) reconnect (nach suspend. netzwerkfehler, whatever) - ist das eigentlich schon supposed to work? (vermute nein)

2) 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?

Makki

[makki]

Mehr so etwas:

Hmm, ich kann doch nur googeln&kopieren, nicht programmieren
So ne Kugel hab ich jetzt nicht gefunden, auf die schnelle kann ich nur das hier anbieten: (auf klicken

Woher der Sinneswandel? Ich finds ehrlichgesagt immernoch überflüssige spielerei, aber es sieht einfach cool aus sowas
Und es ist relativ leicht zu implementieren, vielleicht ist mir langweilig..

Makki

[mkeil]

zum thema slider: ich habe die slider mal auf iphone und andoid getestet und sie funktionieren nicht.

ich habe evtl einen fix dafür ausfindig gemacht. und würde den lokal testen und mich dann wieder melden

Ich zitiere mich mal selber.
Also ich hab eine Lösung allerdings erstmal nur zufriedenstellend für apple-devices. mein android phone will mit dem patch nicht arbeiten.

den patch bekommt man hier: jquery-ui-for-ipad-and-iphone - Project Hosting on Google Code
ich hab ihn lokal bei mir eingebunden. der malus dabei ist das man die seite auf den devices nicht mehr "herumschubsen" kann da die touchevents umgebogen werden (sollte ja aber bei einer visu auch nicht der fall sein).

Markus

[Chris M.]

Und richtig, man kann. Blöd, wenn man muss.

Das ist ganz einfach:
Mein aktuelles Ziel ist möglichst schnell die interne Beta-Phase zu beenden und zur offiziellen überzugehen. Dazu muss der Code reifen, massentauglich werden und raus. Alles was ablenkt ist tendenziell kontraproduktiv - ich nehme es gerne in die Feature-Requests auf (noch besser: auf SourceForge selber eintragen...), gehe es aber noch nicht aktiv an (außer mir ist langweilig und ich will abwechslung...). Ein Slider statt einem Kreis wäre hier eine 20/80 Lösung - und damit eine Lösung.

ABER:
Das hier ist ein OpenSource Projekt. Und da entscheidet der, der die Arbeit macht. Wenn mir jemand so ein Widget schreibt und eincheckt - warum nicht? Wir haben hier noch keinen Feature-Freeze ausgerufen...

[MatthiasS]

Mehr so etwas:



Ein Klick und du bist am Ziel.