CometVisu - (interner) Beta-Test

[luigi4711]

Authentication & Authorization evt. !?

[NilsS]

Authentication & Authorization evt. !?

oder Authorization & Accounting

Authentication sollte doch Sache des Webservers bleiben.

Authorization darf jedoch nur im backend erfolgen, da wenn die Quelle der Authorization im XML auf dem Client liegt, dann lässt sie sich auch auf dem Client manipulieren.

Ich hab für PyWireGate schon etwas geplant, bin aber noch nicht soweit.

[Bodo]

Hoi
Ich bin gerade ein bischen am testen und kann momentan das edit widget nicht mit ok verlassen.

[netzkind]

Hoi
Ich bin gerade ein bischen am testen und kann momentan das edit widget nicht mit ok verlassen.

Dann müsste der Browser einen Javascript-Fehler melden. Der wäre interessant

Grüße,
Julian

[Bodo]

jquery.js (Zeile 1788)
elem.attributes is undefined
[Break on this error] if ( !elem.attributes[ name ] && (el...te && !elem.hasAttribute( name )) ) {

PS: Vor einigen Tagen ging's noch.

[netzkind]

jquery.js (Zeile 1788)
elem.attributes is undefined
[Break on this error] if ( !elem.attributes[ name ] && (el...te && !elem.hasAttribute( name )) ) {

Benutzt du den aktuellen SVN-Stand? Die Fehlermeldung schaut wie das aus was ich mit jQuery 1.4.4 beobachtet habe.
Der SVN-Stand ist deswegen "known defective", das Release 0.5.1 hingegen sollte hier funktionieren.

Grüße,
Julian

[Bodo]

Erledigt

Hoi
Gut ich hatte den trunk genommen:
Revisionen:
visu/ 162
lib/ 147
jquery.js 146
Da ist die --- jQuery JavaScript Library v1.4.4 --- drin.

Ok ich gucke release_0.5.1/

Edit: da ist --- jQuery JavaScript Library v1.4.2 --- drin
Erst selbes Verhalten, dann den Cache geleert, jetzt funzt's natürlich
Na ich lass Euch mal in Ruhe weitermachen

[luigi4711]

Hab gerade versucht ein Package Update übers Webif auf cometvisu 0.5.1 zu machen. Irgendwie scheint er aber am Ende die Frage, was er nun mit der visu_config.xml machen soll, nicht sauber abzufangen?

Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be upgraded:
  cometvisu
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 576kB of archives.
After this operation, 0B of additional disk space will be used.
Get:1 http://repo.wiregate.de wiregate-0.1/main cometvisu 0.5.1-1 [576kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 576kB in 3s (149kB/s)
(Reading database ... 48481 files and directories currently installed.)
Preparing to replace cometvisu 0.5-1 (using .../cometvisu_0.5.1-1_all.deb) ...
Unpacking replacement cometvisu ...
Available modules: auth cgi fastcgi proxy rrdtool simple-vhost ssi ssl status userdir cgi-cometvisu
 
Already enabled modules: cgi cgi-cometvisu 
Disabling cgi-cometvisu
Run /etc/init.d/lighttpd force-reload to enable changes
Setting up cometvisu (0.5.1-1) ...

Configuration file `/var/www/visu/visu_config.xml'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : background this process to examine the situation
 The default action is to keep your current version.
*** visu_config.xml (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing cometvisu (--configure):
 EOF on stdin at conffile prompt
Errors were encountered while processing:
 cometvisu
E: Sub-process /usr/bin/dpkg returned an error code (1)

Als Folge hat er nun ein unvollständig installiertes Paket:

Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Conf cometvisu (0.5.1-1 stable)

Fehlt da noch was, um eine geänderte XML beim Package Update besser abzufangen!? Das WG Webinterface bietet ja an der Stelle auch dem User keine Möglichkeit der Eingabe, oder!?

luigi

[vento66]

Du kannst dich direkt auf die Konsole einklinken (entweder Putty oder ähnliches)
und
apt-get update
apt-get install cometvisu

Die Visu_config.xml muss später noch in ein anderes Verzeichniss, damit die Abfrage nicht mehr kommt. bzw eine benutzerdefinierte config nicht überschrieben wird. im Moment ist das noch notwendig, da die config.xml vom Grundgerüst her noch nicht auf dem Release Stand ist.

[luigi4711]

Das mit der command-line ist mir klar, wollte nur sicherstellen, dass das für den DAU später gefixt wird. Trotzdem danke.

luigi

[makki]

Zumindest das Authentication war gemeint, ja
Das runde Gesamtkonzept dafür (Anwenderfreundlich, kein generve mit paranoia-Security aber eben trotzdem sicher) ist im Kopf aber auch noch im Beta-Stadium.
Ich denke ich werde morgen nochmal ein Package machen, wo man das vielleicht ein bisschen elaboriert.

@luigi: jep, das ist auf der Liste aber aktuell ein "halbabsichtlicher Bug" (weil das das passiert war mir vorher klar, nur entweder, wenn man jetzt einsteigt: kommt man ohne config raus->viel mehr gefummel als Konsole&eine Frage..)


Nebenbei: was heute im Telefonat mit Nils noch hochkam: eine allzugrosse Abhängigkeit von KNX-only (DPT) sollte man IMHO auch im Editor vermeiden, KNX ist nur eines von vielen möglichen, wo sich die Visu ihr Futter holt.
Andererseits muss ich das aber gleich selber verteidigen Der KNX hat seine sinnvollen Spezifikas wie z.B. bei einem Dimmer (Schalten,Schaltstatus,Dimmen,Dimmwert,Dimmwertsta tus - um nur ein Beispiel zu nennen) - die man dort auch abbilden sollte. Schon alleine weil die Leute das verstehen.

Für einen FS20-Dimmer (oder einen falsch verstandenen KNX-Dimmer) wirds dann halt ein zweites Widget geben müssen.. Dimmwert->Ende. Status obliegt hier Kommisar Zufall

Makki

[Chris M.]

eine allzugrosse Abhängigkeit von KNX-only (DPT) sollte man IMHO auch im Editor vermeiden, KNX ist nur eines von vielen möglichen, wo sich die Visu ihr Futter holt.

Richtig. Daneben fallen mir spontan noch die (für mich relevanten) Logik-Engine, xPL und OPC UA ein. Daneben wollen die ganzen FS20, LON, LCN, ... auch nicht vergessen sein.

[makki]

LCN

Gut, LCN würde ich jetzt schon vergessen, weil das ist ungefähr so relevant wie hierzulande X10; ich glaube selbst der FS20-Schrott hat 1000% mehr Marktdurchdringung
(obwohl das mal interessant wäre: FS20 vs. KNX in Stückzahlen im EFH, brr, ich fürchte, ich wills nicht wissen! bin schon ruhig )

Aber im Kern 100% d'accord: KNX ist nicht die einzige Wahrheit, spätestens bei der Mediensteuerung ist nunmal ziemlich Schluss (ausser man kann, will&muss sich durchs Knie usw..)

-> Das kann, muss & wird direkt passieren müssen (wie auch immer, ob über die iFrame-"Notlösung" die ich aus Faulheit - und als gebranntes Kind - erstmal präferiere oder "nativ/direkt")

Makki

[luigi4711]

@Netzkind
Noch mal zu dem Thema GA Auswahl im Editor. Momentan scheint sich der Editor wirklich noch komplett auf die eibga.conf zu verlassen und nicht, was in der Visu XML tatsächlich eingetragen ist.

Beispiel:

      <info address="2/2/11" datatype="5.001" styling="BluePurpleRed">Status Ventilstellung</info>

Diese GA ist nicht in der eibga.conf angelegt. Wenn ich nun dieses Widget mit dem Editor bearbeiten will, zeigt er mir eine unvollständige Maske mit fehlender Adresse.

Sollte er nicht zumindest die GA anzeigen, auch wenn er keine weiteren Infos wie z.B. die Bezeichnung aus der eibga.conf holen kann!?

luigi

[Chris M.]

Gerade habe zwei neue Dinge in's SVN geladen:

New Feature: Plugins
New Plugin: colorChooser (based on farbtastic)

Das unwichtigere (auch wenn's MatthiasS unbedingt wollte... ) ist der Farbwähler, selbstverständlich nicht als RGB sondern als HSL
(Vom verwendeten "Widget" gäbe es auch noch eine Beta Version 2.0 die canvas statt fixer Bilder nutzt und daher skalierbar wäre. Den IE Nutzern will ich die aber erst mal ersparen...)

Das für die CometVisu wesentlich wichtigere sind die Plugins. Das sind aufwändige Widgets, etc. die mehr Ressourcen nutzen als man jemanden als unnötigen Overhead zumuten möchte. Der colorChooser bringt so eine eigene extra JavaScript Datei, eine CSS und ein paar Bilder mit...
Außerdem können Plugins mit dem Paket mitgeliefert werden (oder von extra Plugin-Autoren als eigene Pakete bereit gestellt werden)
(Die Custom-Widgets in der structure_custom.js dagegen sind kleine, leichtgewichtige Widgets die für lokale Anpassungen geeignet sind - wie der Design-Switcher, der keine Bedeutung für die Allgemeinheit hat).

Die Frage, die sich mir nun stellt:
Die visu_config.xml wird auf der obersten Ebene nun immer unübersichtlicher. Sollen wir eine neue Ebene "meta" einfügen und dort die plugins, mappings und stylings drunter kopieren? Oder ist das egal?

Und da wir gerade bei der Syntax der visu_config.xml sind, gibt es hier noch Verbesserungsvorschläge? Noch können die Syntax beliebig ändern, da die Nutzerbasis klein genug ist. Nach der öffentlichen Beta wird's schwieriger...