CometVisu - (interner) Beta-Test

[Chris M.]

Im Source hatte ich noch zwei Zeilen vergessen zu ändern - d.h. spätestens jetzt sollte es wieder gehen (aber die eigene visu_config.xml anpassen nicht übersehen, s.o.)

[Chris M.]

So die aktuelle Visu aus dem svn bringt nur einen black screen, die Fehlerkonsole meldet unter Chrome:

Failed to load resource: the server responded with a status of 404 (Not Found)
visu_svn/visu/plugins/colorChooser/structure_plugin.js

Uncaught TypeError: Cannot call method 'create' of undefined
/visu_svn/visu/lib/templateengine.js:233

Das erstere lässt sich mit umbenennen des Ordners colorchooser nach colorChooser beheben, für die 2. Meldung fehlts mir dann an Wissen

Nein, bitte nicht den Ordner umbenennen - den habe ich wg. dem Kommentar zum camelCase extra in lowercase umbenannt.
Ich vermute, dass Du Deine visu_config.xml noch diesbezüglich anpassen musst.

Übrigens: entwickeln tu ich unter FF, meine Visu läuft mit Chromium. (Und um vom Arbeitsplatz mal schnell schaun zu können, hab ich Interesse an IE7)

[vento66]

So die aktuelle Visu aus dem svn bringt nur einen black screen, die Fehlerkonsole meldet unter Chrome:

Failed to load resource: the server responded with a status of 404 (Not Found)
visu_svn/visu/plugins/colorChooser/structure_plugin.js

Uncaught TypeError: Cannot call method 'create' of undefined
/visu_svn/visu/lib/templateengine.js:233

Das erstere lässt sich mit umbenennen des Ordners colorchooser nach colorChooser beheben, für die 2. Meldung fehlts mir dann an Wissen

[makki]

lief es da denn überhaupt schon mal?

Definitiv, ja ich kann Dir aber ehrlichgesagt nicht sagen wann&was; heute Nachmittag klappte das mit einer noch, ich glaube es war post 0.5.1 aber pre-SVN von heute.
Die Visu selbst ist im Chrome sogar hier erheblich "smoother" als im FF (ich vermute aber Chris entwickelt auch mit Chromium, weil von ihm hab ich den Trigger dafür)
-> Mein neuer Lieblingsbrowser, ist dasselbe wie FF vor ein paar Jahren: schlank, schön, schnell

Hier auch 7.0.517.44 (64615) Ubuntu 10.04

Makki

P.S.: Damit Mitleser das auch einsortiert bekommen: Chrom(ium) basiert auf Webkit, eine aktuell wohl als eher ziemlich gut angesehene OSS "Browser-Engine" - auf der auch der Safari basiert.
Wir denken hier also auch an die iStore-Junkies

P.P.S.: Wenn mir jemand das mit dem Cache-leeren erklären kann -> ??
Ich hab jetzt mal ein bisschen getestet; ändere ich ein .js am Server reicht in 100% der Fälle ein normaler F5 und die aktuelle Version wird geholt.
Ich kreide das ja nicht der Cometvisu an, sondern entweder dem client (daran kann ich nix ändern, nur workarounds bauen) oder dem Server (daran könnte ich was ändern!).
Aber es ist IMHO ein zu lösendes Problem, bei einem Update Cache leeren ist ein Workaround, kein Fix

[netzkind]

r172:
- im Chromium gehen die Edit-Dropdowns jetzt seit dem letzten Update nur noch "irgendwann"

Kann ich hier Chrome 7.0.517.44 reproduzieren - der lässt mich nicht mal mehr in die inputs schreiben. Spontan hab ich keine Idee woran das liegt - habe es aber auch noch nie mit Chrome probiert gehabt: lief es da denn überhaupt schon mal?

Grüße,
Julian

[makki]

Browser-Cache

Peinlich, peinlich
Mit Cache leeren gehts im FF, bisher hat strg+F5 immer gereicht;

Und selbst das sollte doch nicht notwendig sein! Ich werd das "fürs Feld" jetzt mal näher untersuchen und was man ggfs. dagegen tun kann, weil eigentlich frägt der Client den Server ja deswegen mit "If-Modified-Since" + all dem Zeugs im Header.
Und der Server antwortet doch bitte nur mit 304 wenns seitdem nicht geändert ist (oder eben nicht wenn geändert) !?!
Da fehlt evtl. noch ne klitzekleine Einstellung..

Makki

[netzkind]

@makki:
ich hab grade bei mir mal den cache geleert und anschließend mit FF 3.6.12 http://mm-ho.dyndns.org/visu-svn/ geöffnet - bei mir läufts problemlos.

Cache leeren um keine alten JS einzubinden?

Grüße,
Julian

[makki]

Soweit meine Vermutung.

100 Punkte
Wenn ok, kann ich das auch gleich commiten ?

Edit: An den Dropdowns im Editor mit Chromium ändert das aber nichts..
STOP: Kommando zurück! Lowercase ändert nichts, schon schlau wenn man 20 Fenster offenhat, die eine SVN ändert und dann im C statt FF anschaut

Makki

[netzkind]

- Die normale Visu sagt im FF jetzt zwar keine JS-Fehler mehr, aber es steht nur noch loading da ?
Evtl. hab ich das irgendwas an der config.xml versaut?

Ich hab irgendwo im Kopf dass bei xml alle Attribute und tags lowercase sein sollen. Soweit richtig. Das Plugin für den Farbwähler ist aber camelcase - deswegen kommt es dann zu Problemen beim Benutzen des Plugins.

Wahrscheinlich am besten das Verzeichnis plugins/colorChooser, den plugins-Eintrag in der XML und den Namen des Plugins in plugins/colorChooser/structure_plugin.js auf lowercase umzustellen - denn ich würde annehmen dass die DOMDocument-lib von PHP uns die Tags immer wieder auf lowercase stellen wird.

Soweit meine Vermutung.

Grüße,
Julian

[makki]

Mit "Plugin" hab ich jetzt nicht soviel Schmerz, weil der Anwender davon im Normalfall ja nichts mitbekommen wird. Visu release x wird Funktion Y haben, der Rest ist eher entwicklergespräch und da werden wir schon unterscheiden können
Man kann ja im öffentlichen Sprech ein bisschen darauf achten und das deutlich mit Visu oder js "prefixen"..

r172:
- im Chromium gehen die Edit-Dropdowns jetzt seit dem letzten Update nur noch "irgendwann"
- im FF geht kein Ok mehr -> hat aber evtl. damit zu tun:
- Die normale Visu sagt im FF jetzt zwar keine JS-Fehler mehr, aber es steht nur noch loading da ?
Evtl. hab ich das irgendwas an der config.xml versaut?

Makki

[Chris M.]

diese Argumentation kenne ich nur im Zusammenhang mit Web-Performance, wobei es darum geht dass ein User im Laufe eines Webseitenbesuches praktisch dauernd neue Seiten öffnet und dabei der Browser jedes mal eine Menge requests an den Server schicken muss, und sei es nur um sie mit 304 (not modified) beantwortet zu bekommen. Da der Browser auch noch eingebaute Limits hat wie viele Anfragen er pro Server parallel abschickt sollte man hier lieber mit wenigen Dateien arbeiten.

Stimmt, dass uns das nicht so stark beißt.
Wie ist denn der Lage bei einem Smartphone-User (der Worst-Case öfters mal die Verbindung aufbaut, da mal schnell nach dem Status geschaut werden soll, und außerdem eine langsame Verbindung, da der gerade mit grenzwertigem GSM auf der Berghütte sitzt)? (Mangels Smartphone kann ich das nicht beantworten...)

Mein Hauptpunkt war aber, dass ich es ungeschickt finde die explizite Ladeanweisung für Plugins in die Konfiguration mit aufzunehmen.

Na wenn dass Deine Sorge ist: wie wäre es statt explizitem mit implizitem Laden?
D.h. wenn die templateengine ein Widget nicht kennt, könnte die ja probieren dieses als Plugin zu laden (diese Vorgehen habe ich nicht getestet, kann mir aber vorstellen, dass das funktionieren könnte).
Man verliert nur die Möglichkeit für dieses Plugin globale Einstellungen zu machen (aktuell nicht implementiert - und vermutlich auch nicht wirklich wichtig, da man ja die Widget spezifischen Einstellungen noch hat)

[Chris M.]

So, die Trunk-Demo ist jetzt auch wirklich die aktuelle SVN-Version

Aber im FF hab ich damit:
[...]

Hab gerade mal was hochgeladen (ungetestet...) das da hoffentlich hilft. (Wenn keine Verbindung besteht, versucht er auch kein abort() mehr)

[netzkind]

Hi Bodo,

<div id="main" style="width:900px;position:relative; overflow: hidden;"  style="display: none;">

"Warning" Zeile 21 Pos 5 repeated attribute "style"

stimmt, hab ich im SVN jetzt noch mit 171 behoben, und das "Einblenden" auch für den Editor eingefügt. Danke!

Zusätzlich kann man jetzt im Editor auch eine GA eingeben die nicht in der Liste ist.
Das Design dafür ist momentan noch grausam ... ich hab aber auch das Gefühl dass es im usability-Thread im Moment ein wenig stockt, davon würde ich mir noch mehr Input wünschen (auch für diese Art der Elemente).

Grüße,
Julian

[makki]

So, die Trunk-Demo ist jetzt auch wirklich die aktuelle SVN-Version

Aber im FF hab ich damit:

this.xhr.abort is not a function
http://172.17.2.65/visu-svn/lib/cometvisu-client.js
Line 140

Da ist man zwei Tage weg und hat 2kg lesestoff

Makki

[netzkind]

Hi Chris,

Den gänigen JavaScript-Performance-Anleitungen zufolge sollte man tunlichst vermeiden, viele kleine JavaScript Dateien zu laden und statt dessen lieber eine große zu nehmen. (Das hat eigentlich auch eine Auswirkung auf das Package, dass genau diesen Schritt machen sollte - aber das können wir gerne auf eine späte Beta verschieben)

diese Argumentation kenne ich nur im Zusammenhang mit Web-Performance, wobei es darum geht dass ein User im Laufe eines Webseitenbesuches praktisch dauernd neue Seiten öffnet und dabei der Browser jedes mal eine Menge requests an den Server schicken muss, und sei es nur um sie mit 304 (not modified) beantwortet zu bekommen. Da der Browser auch noch eingebaute Limits hat wie viele Anfragen er pro Server parallel abschickt sollte man hier lieber mit wenigen Dateien arbeiten.

Das Szenario bei der Visu ist aber ein anderes wenn man davon ausgeht, dass die Visu einmal geöffnet wird und dann lange offen bleibt. Denn da spielt das Laden der vielen kleinen Dateien keine so große Rolle.

Mein Hauptpunkt war aber, dass ich es ungeschickt finde die explizite Ladeanweisung für Plugins in die Konfiguration mit aufzunehmen.

Grüße,
Julian