CometVisu - (interner) Beta-Test

[makki]

caching visu_config.xml

Eben war es wieder soweit, diesmal nichts angefasst und Wireshark angeworfen:
weder F5 noch CTRL+F5 veranlasst den lieben FF auch nur einen einzigen Ansatz eines Requests dafür zu schicken

Wenn man den Cache leert, klar, dann lüppts..
Mal zwecks Doku/referenz, sieht dann so aus:

GET /visu-svn/visu_config.xml HTTP/1.1
Host: 172.17.2.65
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.13) Gecko/20101206 Ubuntu/10.10 (maverick) Firefox/3.6.13
Accept: */*
Accept-Language: de,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
X-Requested-With: XMLHttpRequest
Referer: http://172.17.2.65/visu-svn/
Cookie: testing=1; sid=5aaa82aae548ee10403a3dc3d0e93645

HTTP/1.1 200 OK
Vary: Accept-Encoding
Content-Encoding: gzip
Last-Modified: Thu, 10 Feb 2011 20:03:38 GMT
ETag: "-2018019665"
Content-Type: application/xml
Accept-Ranges: bytes
Content-Length: 2026
Date: Thu, 10 Feb 2011 20:34:48 GMT
Server: lighttpd/1.4.19

Im XHR ist ja eh schon no-cache hart gesetzt soweit ich das sehe, ich fummle da jetzt bei mir mal nen expires-header rein, vielleicht bringts was..

Edit: Expires und Cache-Control Header scheinen zu wirken, dem lieben FF hier manieren beizubringen (mittels mod_expire, zumndest wenn man nach ca. 45 Minuten rausgefunden hat, wie die config-syntax im lighty dafür nun genau ist )
Werd das mal irgendwie einbauen mit so 10 sek. für *.xml oder so (der Webserver sagt dann trotzdem 304 Not modified, aber sonst fragt der FF wohl einfach meistens nicht..)

Edit2: bisher kannte ich mod_expires nur, um das gegenteil zu erreichen: mögichst endlich cachen; sollte wir dann glaube ich auch für *.css, *.js (weitere?) machen (?) Der 304-unmodified vom Server kostet ja fast nichts..
Das Verhalten des lighty - auch mit mod_compress (wir sind ja totale sparfüchse und zippen selbst dynamische Daten - bringts über UMTS&co aber z.B auch messbar!) ist da nach meinen Tests einwandfrei.

Makki

[Chris M.]

Nein, das ist im Code derzeit nicht enthalten, wäre aber relativ leicht vorstellbar und sicher auch für andere Stellen praktisch.

Kannst Du das noch in den Editor einbauen?

Ich glaube so rum ist das leichter, als wenn die Widgets vorlegen und dann der Editor nachziehen müsste...

[Chris M.]

wenn bereits eine Version vorhanden ist, also auch eine visu_config.xml,
dann wartet er auf eine Eingabe wie verfahren werden soll.

Das ist ein bekanntes Problem, dass jetzt hoffentlich gelöst werden kann, da die Demo-Config ja nun von der normalen (User) Config getrennt ist.

Nach "apg-get install cometvisu" via console habe ich es mal überschrieben.
=> Meine alte visu_config.xml scheint nicht kompatible zu sein.
Zumindest wird Sie nicht geladen.

Wenn Du nur die Pakete einsetzt (und nicht das Subversion Repository), dann ist genau das zu erwarten und ist daher auch bei den Release-Infos immer mit angegeben worden.
Diese, nicht rückwärtskompatible, Änderung der Config-Formates war ja auch der Hauptgrund für dieses Release.

Hallo zur Info,
wenn bereits eine Version vorhanden ist, also auch eine visu_config.xml,
dann wartet er auf eine Eingabe wie verfahren werden soll.

Nach "apg-get install cometvisu" via console habe ich es mal überschrieben.
=> Meine alte visu_config.xml scheint nicht kompatible zu sein.
Zumindest wird Sie nicht geladen.

[netzkind]

@Julian:Vermutlich steht's im Code, aber Du kannst mir sicher schneller die Antwort geben:
Kann ich ein Widget-Parameter machen, der aus einer Auswahlliste befüllt wird?

Nein, das ist im Code derzeit nicht enthalten, wäre aber relativ leicht vorstellbar und sicher auch für andere Stellen praktisch. Bislang gibt es nur die absolut dynamischen select-Listen für DPT, GA, Mapping und style.

[Chris M.]

@Julian:Vermutlich steht's im Code, aber Du kannst mir sicher schneller die Antwort geben:
Kann ich ein Widget-Parameter machen, der aus einer Auswahlliste befüllt wird?

(Konkret: Ich würde gern ein paar generische Widgets machen, die durch eine zweite Auswahlliste erst genauer spezifiziert werden. Ein Beispiel ist das Diagramm das wir z.Zt. als _inline und als _popup haben, also zwei Widgets. Das macht aber keinen Sinn, da es ja genau das selbe ist, nämlich ein Diagram-Widget mit den identischen Parametern. Folglich könnte es einen "Subtyp" geben der in einer Auswahlliste das "inline" oder das "popup" auswählen lässt.)

[manu241]

Hallo,

was mir noch aufgefallen ist, Texte kann ich in dem Widget zentrieren, Links zu anderen Seiten aber nicht.

Gruß Manuel

[Chris M.]

kann es sein, das aus der Demo die Seite mit den Temperaturen verschwunden ist ?

Ja.
Die Demo-Seite basierte bisher auf meiner Visu + jedem Widget das es gibt zum Testen und quasi als Doku wie man's verwenden kann.

Das macht aber auf Dauer keinen Sinn, folglich ist die Aufteilung nun so:

• visu_config.xml - die "default" Visu und damit die, die vom Anwender überschrieben werden sollte. Somit ist die auch sehr leer. Und enthält unten einen Link auf die Demo-Visu:
• visu_config_demo.xml - die neue Demo-Visu auf der alle Möglichkeiten und damit Widgets enthalten sind, möglichst mit GAs die vermutlich wenig Schaden anrichten wenn die wild verschickt werden.

Da ich heute ein Update gemacht habe, musste ich die visu_config.xml
wieder beschreibbar machen. Ist das so gewollt ? Oder kann man das von vorne rein ändern ?

IMHO sollte die das Package schreibbar machen und nur anlegen, wenn noch nicht vorhanden.

[manu241]

Hallo,

kann es sein, das aus der Demo die Seite mit den Temperaturen verschwunden ist ?

Da ich heute ein Update gemacht habe, musste ich die visu_config.xml
wieder beschreibbar machen. Ist das so gewollt ? Oder kann man das von vorne rein ändern ?

Gruß Manuel

[makki]

@luigi: klar, richtig, meckert er natürlich auch.. Aber genau darum gehts auch->Feedback damit man sowas vermeiden kann ohne Dumm-Dumm die config beim Anwender zu nullen (deswegen mache ich das ja, überschreiben wäre einfach..)

Makki

[Chris M.]

Ich habe soeben meinen ersten Bug in Sourceforge erstellt.

Der sieht doch schon mal ganz passend aus

Man möge mir verzeihen, wenn da etwas nicht ganz richtig ist. Festhalten wollte ich folgendes Verhalten (der Screenshot ist auch als Attachment in Sourceforge), dass eine embedded Grafik und ein inline Diagram über ihren Bereich hinaus gehen.

Das ist ein schweres Thema (vor dem ich bisher weggelaufen bin...) - aber ein sehr wichtiges!

[luigi4711]

Ich habe soeben meinen ersten Bug in Sourceforge erstellt. Man möge mir verzeihen, wenn da etwas nicht ganz richtig ist. Festhalten wollte ich folgendes Verhalten (der Screenshot ist auch als Attachment in Sourceforge), dass eine embedded Grafik und ein inline Diagram über ihren Bereich hinaus gehen.

[luigi4711]

ist online..

Beim Update (noch bis zum rel PL27) knatscht es wegen der visu_config.xml, also diese entweder vorher aus dem Weg schaffen (die alte ist eh nicht mehr valid) oder per Konsole installieren.

Makki

Wie gehabt, selbst bei wegschaffen meckert er noch (file has been deleted by you...)
Im Moment ist also Konsole der einzige Weg.

luigi

[Chris M.]

sprintf: ich fände es gut. Klar, ist erklärungsbedürftig aber das ist jegliches andere, was man sich ausdenkt auch.. printf hat den Vorteil, das es 1Mio Beispiele mit Google gibt..

Das ist natürlich richtig. Ggf. kann man ja da auch per Online-Hilfe weiterhelfen. Und ganz dumm wird ein Visu-Ersteller auch nicht sein, als dass er sich in diese Codierung eindenken könnte...

Release: ich hatte es befürchtet und heute schon den ganzen Nachmittag etwas "den Hof gekehrt"

Hab ich schon gesehen.
Ansonsten sind Versionsnummern sehr preiswert. Und mir war es wichtiger die neuen Designs zu veröffentlichen und jetzt schon mal die Testbasis zu verbreitern. So können wir aufräumen und polieren, während andere testen können - was v.a. wegen der starken Änderung am Unterbau wichtig ist.

Wichtiger Hinweis an alle Tester: das Format der Config-Datei ist jetzt hoffentlich stabil, d.h. die Visus, die ihr erstellt, werden auch in Zukunft funktionieren. Wenn man jetzt eine komplexere Visu erstellt, ist die Arbeit also zukunftskompatibel.

Weiterer wichtiger Hinweis: das war eine Willenserklärung - aber keine Garantie...

Was ich mir selbst für nächste Woche auf die Agenda geschrieben habe ist:
[...]
(das sind für mich so die Showstopper, deswegen mache ich dafür jetzt auch keine Bugs auf sondern versuche es lieber zu fixen )

Klar, wenn's so klein ist, dass der Fix schneller als der Bug-Report geht dann macht man den besser gleich.
Aber sonst ist ein Bug-Report nicht verkehrt, da man so besser koordinieren kann, wer sich um was kümmert.

Der Slider ist IMHO übrigens in der Praxis immernoch überflüssig wie ein Kropf, aber das erste was man sieht, also doch sehr wichtig..

Ach ja, und ein RTR-Widget für die "analogen" brauchts IMHO noch für die elementare Grundausstattung. Soll,Ist, Komfort usw. Der Sinn dieser hat sich mir zwar ebenfalls nie ganz erschlossen (Sollwert und eine Änderung dieses tuts genauso), ist aber halt so..

Slider finde ich nicht schlecht - aber jeder darf natürlich nehmen, was er will
Wegen dem RTR-Widget schau ich mal was geht...

Ich hatte vorhin auch wieder das Phänomen, das die .xml nicht aktuell geladen wurde, kann es aktuell (wo ich nun sniffe.. grummel) aber nicht mehr reproduzieren.

Das ist ein echt nerviges und hartnäckiges Problem

[makki]

Paket 0.5.3

ist online..

Beim Update (noch bis zum rel PL27) knatscht es wegen der visu_config.xml, also diese entweder vorher aus dem Weg schaffen (die alte ist eh nicht mehr valid) oder per Konsole installieren.

Makki