CometVisu - (interner) Beta-Test

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

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

Gruß Manuel

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

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

[tjakobi]

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.

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

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

[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

[makki]

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

Ist auch so beabsichtigt, ein bisschen dämlich aber so wird wenigstens nichts ungefragt überschrieben und der Anwender gezwungen, sich mit der Frage zu beschäftigen
Mit dem nächsten Patchlevel wird das allerdings (für alle Packerl beim Update via Webif) geändert: dann werden geänderte configs grundsätzlich nicht überschrieben aber auch keine dummen Fragen mehr gestellt - und ggfs. die aus dem Paket als .dpkg-dist abgelegt.
Für das Debian-Paketverwaltungssystem braucht man wohl ein paar Jahre, ist so

Makki

[Chris M.]

Eben war es wieder soweit,

Gerade beim Entwicklen ärgert er mich hier wieder

mod_compress (wir sind ja totale sparfüchse und zippen selbst dynamische Daten - bringts über UMTS&co aber z.B auch messbar!)

Das ist eigentlich eine einfache Rechnung, wenn das Zippen und Entzippen schneller ist als die dadurch gesparten Bytes durch die Luft zu jagen dann lohnt sich das.
Oder anders gesagt, wenn wir ganz optimal sein wollten, müssten wir je nach Endgerät und Übertragungsstrecke das dynamisch einstellen...
Pragmatisch: einfach immer komprimieren

Nun was anderes @Julian:
Im Code sehe ich nun etwas wie

address:    { type: 'address',   required: true, multi: true }

Das wollte ich gleich mal missbrauchen beim Basteln eines Multiswitches / Multitriggers (der für Szenen aber auch für den Heizungbetriebsmodus verwendet werden soll) und hatte für die Beschriftung von n Buttons eine Zeile wie

button:     { type: 'string',    required: true, multi: true },

einfügen.
Leider funktioniert die nicht so wie erwartet (nämlich dass nun ein "String-Multiedit" erscheint).
--> Ist das zu erwarten, oder mache ich da was falsch?

[makki]

Gerade beim Entwicklen ärgert er mich hier wieder

Naja, nicht nur beim entwickeln, wenn die config geändert wird und der Browser die alte bis zum St.nimmerleinstag cached ist auch nicht toll

Aber das mod_expire scheint da zu wirken..

Quickfix: (wie ich das zuverlässig per Paket einfummle muss ich mir noch ausdenken)

root@wiregate231:~# cat /etc/lighttpd/lighttpd.conf
# Debian lighttpd configuration file
#

############ Options you really have to take care of ####################

## modules to load
# mod_access, mod_accesslog and mod_alias are loaded by default
# all other module should only be loaded if neccesary
# - saves some time
# - saves memory

server.modules              = (
            "mod_access",
            "mod_alias",
            "mod_accesslog",
[B]# load expire BEFORE mod_compress!
            "mod_expire",
[/B]            "mod_compress",
..

[B]$HTTP["url"] =~ "\.xml" {
    expire.url = ( "" => "access plus 10 seconds" )
}
[/B]

Oder hardcore: Global (ohne $HTTP..), zum entwickeln vielleicht praktisch, fürn echtbetrieb nicht so das wahre:

expire.url = ( "/" => "access plus 5 seconds" )

und (Edit: einmalig)

root@wiregate231:~# rm /var/cache/lighttpd/compress/visu-svn/*.xml

Makki

[netzkind]

Hi Chris,

Nun was anderes @Julian:
Im Code sehe ich nun etwas wie

address:    { type: 'address',   required: true, multi: true }

Das wollte ich gleich mal missbrauchen beim Basteln eines Multiswitches / Multitriggers (der für Szenen aber auch für den Heizungbetriebsmodus verwendet werden soll) und hatte für die Beschriftung von n Buttons eine Zeile wie

button:     { type: 'string',    required: true, multi: true },

einfügen.
Leider funktioniert die nicht so wie erwartet (nämlich dass nun ein "String-Multiedit" erscheint).
--> Ist das zu erwarten, oder mache ich da was falsch?

Klare Antwort:

Zumindest beim Editor machen wir auch grade definitiv technische Schulden die uns beim nächsten Ändern der Datenstruktur richtig Probleme bereiten dürften. Das Maß in dem beim Editor die Strukturen hartcodiert sind, oder auch die Komplexität der Konstrukte macht den Code schwer wartbar.

Das ist definitiv so erwartet, und wird sich meiner Einschätzung nach niemals ändern, weil der Editor sonst magisch erraten müsste was der Entwickler eines Plugins sich vorstellt dass ein "button"-Tag noch so für Attribute hat, welche Datenbasis für welche Attribute verwendet werden müssen - und vor allem: wie diese Attribute strukturiert dargestellt werden sollen. Falls es dazu Ideen gibt wie man das dynamisieren kann lass ich mich gerne überzeugen

Das mit dem "multi" zielt schon in die richtige Richtung, aber jedes Element das irgendwie als multi dargestellt werden soll muss hartcodiert im Editor bekannt sein. Im Moment rennt das in der visuconfig_edit.js bei Zeile 442ff hier rein:

                            } else {
                                // handling for "if an element can appear more than once"
                                // TODO: needs to be coded once someone wants to use it :)
                            }

Grüße,
Julian

[netzkind]

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

rev #291.

Gleichzeitig bin ich aber davon überzeugt dass wir immer den Editor an die Widgets anpassen müssen: neue Widgets werden neue Anforderungen mitbringen wie und welche "Einstellungen" sie benötigen. Und man kann sich schwer ausmalen was Widgets noch alles abgefahrenes brauchen werden

Grüße,
Julian

PS:
hatte vergessen das "type"-Attribut für Adressen zu committen (was übrigens jetzt einfach so wieder geht) - das ist in rev #290.

[netzkind]

@caching:
das überrascht mich jetzt alles nicht so.

Also: Strg-Reload bringt nichts, weil das XML nicht Teil der Seite ist, sondern per Skript nachgezogen wird - da gilt das "force reload" nicht mehr für den Browser.
Gleichzeitig gab es im Code der templateengine.js bereits eine Zeile die dafür sorgte dass das XML niemals aus dem Cache geladen wird.

Die wurde aber geändert nach:
$.ajaxSetup({cache: !forceReload});

Ok, einfach an die URL "forceReload=true" anhängen, dann lüppts. Ich dachte das wäre in der Demo-Visu im Footer-Link "Reload" mal enthalten gewesen, scheint aber nicht der Fall zu sein.

Siehe hierzu auch:
Two Important Differences between Firefox and IE Caching – HttpWatch Blog

Absatz 2 zu "If You Don’t Specify an Expiration Date Firefox May Set One for You". Er verhält sich also gemäß RFC2616. Details im verlinkten Artikel. Ich nehme mal an dass bspw. Webkit (Chrome, Safari) sich auch nach dieser RFC richten.

Schön sieht man es in Firefox Firebug (siehe angehängtes Bild).

Unser Weg raus ist also dem User zu sagen "lösch deinen Cache" oder einen Reload-Button anbieten der den Cache durch anhängen eines irrelevanten Timestamps an die URLs übergeht (womit wir wieder bei forceReload=true sind).

Grüße,
Julian

[Chris M.]

Naja, nicht nur beim entwickeln, wenn die config geändert wird und der Browser die alte bis zum St.nimmerleinstag cached ist auch nicht toll

Ok, einfach an die URL "forceReload=true" anhängen, dann lüppts. Ich dachte das wäre in der Demo-Visu im Footer-Link "Reload" mal enthalten gewesen, scheint aber nicht der Fall zu sein.

Wie Julian schon geschrieben hat, einfach auf

http://wiregate/visu/?forceReload=true

gehen, dann wird die Config sicher frisch geladen. IIRC war das aber nie Bestandteil beim "Reload"-Link unten auf der Seite... (würde aber Sinn machen)
Wichtig zu wissen ist aber, dass das wirklich nur für die Config gilt - nicht für die CSS, JS, ... was mich beim Entwickeln behindert (aber nicht verhindert ).

[Multi-Einträge]Klare Antwort:[Editor-Hack]

Das war meine Vermutung - aber ich wollte nachfragen, nicht dass das sogar gehen würde und ich trotzdem außenrum programmiert hätte...

Das ist definitiv so erwartet, und wird sich meiner Einschätzung nach niemals ändern, weil der Editor sonst magisch erraten müsste was der Entwickler eines Plugins sich vorstellt dass ein "button"-Tag noch so für Attribute hat, welche Datenbasis für welche Attribute verwendet werden müssen - und vor allem: wie diese Attribute strukturiert dargestellt werden sollen. Falls es dazu Ideen gibt wie man das dynamisieren kann lass ich mich gerne überzeugen

Ideen gibt's sicher, wenn man sich mal die Anforderungen genauer strukturiert. Muss mal drüber nachdenken...

Gleichzeitig bin ich aber davon überzeugt dass wir immer den Editor an die Widgets anpassen müssen: neue Widgets werden neue Anforderungen mitbringen wie und welche "Einstellungen" sie benötigen. Und man kann sich schwer ausmalen was Widgets noch alles abgefahrenes brauchen werden

Klar, keine Frage. Nur wenn man die Anforderung, die beim Widget-Entwickeln entsteht, klar spezifizieren kann, dann ist es angenehmer, wenn die "logische Reihenfolge" eingehalten werden kann. D.h. wenn der Editor vorlegt und das Widget dann das bestehende nutzen kann. (Und spätestens zum jeweiligen Release sollte dann beides zusammenpassen)
Die Zahl dieser Änderungen dürfte aber mit der Zeit eh runter gehen, da das Set an Funktionen ja immer vollständiger wird.