Aktuelle CV Version

[Brn]

Ich fixe das mal. Bitte mal den nächsten Nightly Build testen.

..laut Konsole lädt er jetzt die zu inkludierende Datei, aber es passiert mit deren Inhalt gefühlt nix. Keine Fehleranzeige, aber auch keine Anzeige des inhalts.

[peuter]

Sorry mein Fehler bitte morgen nochmal versuchen.

[Brn]

Hmmm.... 3 Feedbacks zum aktuellen Build:

1.) die Konfigdateien werden jetzt nicht mehr unter <cv-root>/resource/config erwartet, sondern unter <cv-root>/config. Das war ein paar Build vorher auch schon mal so.

2.) Hinsichtlich der inkludierten Dateien fühle ich bei Fehlern keinen Unterschied. Er meldet noch immer beim Aufruf der visu, dass die Konfiguration fehlerhaft ist und überprüft werden sollte, während der checker selber dann meint, alles ist okay.
3.) Was funktioniert: die Einleitung einer inkludierten Datei mittels Layout. Okay. Das ist super. Funktionierenden Blöcke kann man also raus nehmen aus der Datei. Dann nur bitte nicht mehr ändern, weil man den Fehler in größeren Dateien nur noch schwer aufspüren kann, weil der checker keine brauchbaren Hinweise gibt.

[Brn]

Btw: es ist noch immer so, dass die Config-GUI das ganze XML in eine nur 2 oder 3 Zeilen schmeißt, was zu häßlichen XML Dateien führt, die praktisch für einen Menschen nicht mit einem einfachen Editor editierbar sind.

Falls jemand ähnliche Probleme hat, hier der Einzeiler auf der Konsole, den ich mir gebastelt habe:
(visu_config_1.xml ist die mit dem furchtbaren Layout, visu_config_2.xml die Zieldatei mit schönem XML Layout)

cat visu_config_1.xml| python -c 'import sys;import xml.dom.minidom;txt=sys.stdin.read();print xml.dom.minidom.parseString(txt).toprettyxml(encoding="UTF-8",indent="    ")' | grep -v -e '^[[:space:]]*$' > visu_config_2.xml

[peuter]

1.) die Konfigdateien werden jetzt nicht mehr unter <cv-root>/resource/config erwartet, sondern unter <cv-root>/config. Das war ein paar Build vorher auch schon mal so.

Hm, seltsam. Ist mir nicht aufgefallen, fällt mir spontan auch nicht ein warum die gemachten Änderungen da Einfluss drauf haben sollten. Schau ich mir nochmal an.

2.) Hinsichtlich der inkludierten Dateien fühle ich bei Fehlern keinen Unterschied. Er meldet noch immer beim Aufruf der visu, dass die Konfiguration fehlerhaft ist und überprüft werden sollte, während der checker selber dann meint, alles ist okay.
3.) Was funktioniert: die Einleitung einer inkludierten Datei mittels Layout. Okay. Das ist super. Funktionierenden Blöcke kann man also raus nehmen aus der Datei. Dann nur bitte nicht mehr ändern, weil man den Fehler in größeren Dateien nur noch schwer aufspüren kann, weil der checker keine brauchbaren Hinweise gibt.

Hängt beides damit zusammen, dass die checker die inkludierten Dateien gar nicht prüft. Da hatte ich hier ja eine neue Version der check_config.php gepostet, die das tut, für die openHAB-Variante müsste ich das erstmal programmieren, gibt es also noch gar nicht.

Das schlechte formatieren der XML-Datei durch den Editor schaue ich mit auch mal an.

[peuter]

Also ich habe jetzt sowohl unter openHAB als auch einem Apache Webserver mit PHP eine Config-Datei mit dem eingebauten Editor geändert und abgespeichert. Ich kann da keine Änderung in der Formatierung der Datei erkennen. Dein Problem kann ich also leider nicht nachcollziehen.

Auch, dass der Config-Ordner plötzlich nicht im im resources-Ordner sein muss, kann ich nicht reproduzieren. Meine Config-Dateien sind alle in <cv-root>/resource/config. Von dort kann ich sie laden, editieren und auch includen. Das einzige ist, dass man beim include das resource-Verzeichnis nicht mit angeben muss. Wenn man also die Datei <cv-root>/resource/config/part1.xml includen möchte, dann mach man das mit <include src="config/part1.xml"/>. Aber das war vorher auch schon so, zumindest hab ich das immer so getestet und bisher keine Probleme gehabt und auch nichts ändern müssen.

[peuter]

Noch eine kleine Ergänzung: scheinbar nutzt openHAB doch die check_config.php und nichts eigenes. Irgendwann war das mal so (meine ich zumindest). Offensichtlich hab ich das irgendwann mal entfernt und habs vergessen.

Daher sollte dieser PR ausreichen um dem config check das Checken der includierten Dateien beizubringen: https://github.com/CometVisu/CometVisu/pull/726

[Brn]

Wenn man also die Datei &lt;cv-root&gt;/resource/config/part1.xml includen möchte, dann mach man das mit &lt;include src="config/part1.xml"/&gt;. Aber das war vorher auch schon so, zumindest hab ich das immer so getestet und bisher keine Probleme gehabt und auch nichts ändern müssen

Ja, das habe ich auch so genacxht. Steht auch in der Doku. Die inkludieten Dateien werden immer sofort gefunden. Hier ist nur das Ding mit dem Caching, also dass man immer den Namen oder einen Parameter ändern muss, damit die geänderte Datei geladen wird.

Dein Problem kann ich also leider nicht nachcollziehen.

Hmmm.. komisch. Woran kann das liegen?

Noch eine kleine Ergänzung: scheinbar nutzt openHAB doch die check_config.php und nichts eigenes. Irgendwann war das mal so (meine ich zumindest).

Verstehe zwar nicht, was du meinst, nicke aber einfach mal wissend.

[peuter]

Ja, das habe ich auch so genacxht. Steht auch in der Doku. Die inkludieten Dateien werden immer sofort gefunden. Hier ist nur das Ding mit dem Caching, also dass man immer den Namen oder einen Parameter ändern muss, damit die geänderte Datei geladen wird.

Also Dein Caching-Problem klingt irgendwie so als ob der Browser schuld wäre und nicht das CometVisu Caching. Das Caching der CometVisu kannst du komplett abschalten mit dem URL-Parameter "?enableCache=false". Wenn es dann immer noch auftritt, dann ist es der Browser-Cache. Da hilft es vermutlich immer die Developer-Tools auf zu haben (zumindest in Chrome schaltet das den Browser-Cache recht zuverlässig ab). Da man dass ja nur für die "Entwicklung" der Config-Datei braucht, wäre das ein brauchbarer Workaround.

Verstehe zwar nicht, was du meinst, nicke aber einfach mal wissend.

Damit wollte ich sagen, dass Du die check_config.php aus diesem Posting doch nutzen kannst: https://knx-user-forum.de/forum/supp...66#post1266366 weil es entgegen der dort getroffenen Aussage keine Unterschied macht ob man openHAB oder irgendeinen anderen Webserver benutzt

[Brn]

Damit wollte ich sagen, dass Du die check_config.php aus diesem Posting doch nutzen kannst: https://knx-user-forum.de/forum/supp...66#post1266366 weil es entgegen der dort getroffenen Aussage keine Unterschied macht ob man openHAB oder irgendeinen anderen Webserver benutzt

Okay, danke. jetzt habe ich es verstanden.
Ich hatte die check_config-Datei ausgetauscht. Wenn ich eine Visu-config aufrufe, in der eine inkludierte Datei ist, welche aus irgend einem Grund nicht funktioniert, kommt bei der check_config.php folgende Aussage:

/var/www/cometvisu/check_config.php:153: Warning: /var/www/cometvisu/resource/config/ueberblick.xml?ts=180906221250 cannot be read [file] /var/www/cometvisu/check_config.php:160: Warning: '' (boolean) is not assignable to ArrayValue [array_unshift] config

Er hat also ein Problem mit den Parametern. Vermutlich sucht er genau diesen Namen im Dateisystem.

Wenn ich den Parameter ts=... wegnehme, kommt ein Fehler

 [h=2]HTTP ERROR 500[/h] 
Problem accessing /cometvisu/check_config.php. Reason: 
     Server Error Caused by:  
 com.caucho.quercus.QuercusException: com.caucho.quercus.lib.dom.DOMDocument.loadXML: stream:418: expected `</group>' at `</page>' (open at 315)

Ich bin mir nur nicht sicher, ob dies ein bug in der check_config.php ist oder ein Hinweis und nicht abgefangener Fehler, warum er mit der inkludierten Datei ein Problem hat.



@chris-m peuter
Ich hatte mir dabei mal kurz den PHP Quelltext angesehen. Ich bin beeindruckt, dass ihr in diesem Stiel ein ganzes Projekt am laufen habt.
Wenn ich an dieser Stelle einen wirklich nett gemeinten Tipp loswerden darf: trennt unbedingt Logik von Code. Ich verstehe, dass man so ein Projekt nicht einfach so umbaut, aber auf Dauer wäre das sicher ein wichtiger Schritt. Von der Idee und Funktionsumfang finde ich CV toll. Wäre schade, wenn es dann irgendwann mangels Wartbarkeit oder Lesbarkeit zu Problemen kommen würde.

[peuter]

 [h=2]HTTP ERROR 500[/h]
Problem accessing /cometvisu/check_config.php. Reason:
Server Error Caused by:
com.caucho.quercus.QuercusException: com.caucho.quercus.lib.dom.DOMDocument.loadXML: stream:418: expected `</group>' at `</page>' (open at 315)

Ich bin mir nur nicht sicher, ob dies ein bug in der check_config.php ist oder ein Hinweis und nicht abgefangener Fehler, warum er mit der inkludierten Datei ein Problem hat.

Ok ich muss mir das Ganze wohl nochmal unter openHAB ansehen.

Ich hatte mir dabei mal kurz den PHP Quelltext angesehen. Ich bin beeindruckt, dass ihr in diesem Stiel ein ganzes Projekt am laufen habt.
Wenn ich an dieser Stelle einen wirklich nett gemeinten Tipp loswerden darf: trennt unbedingt Logik von Code. Ich verstehe, dass man so ein Projekt nicht einfach so umbaut, aber auf Dauer wäre das sicher ein wichtiger Schritt. Von der Idee und Funktionsumfang finde ich CV toll. Wäre schade, wenn es dann irgendwann mangels Wartbarkeit oder Lesbarkeit zu Problemen kommen würde.

Naja der PHP-Anteil am Source-Code der CometVisu macht ungefähr 5% aus und ist auch nicht "Systemrelevant", sprich keine notwendige Bedingung zum Betrieb der CometVisu. Daher hat der auch keine Priorität beim Refactoring (auch wenn er es nötig hätte, wie Du zu Recht bemerkt hast).
Beim Javascript-Code (der ungefähr 85% des Gesamtcodes ausmacht) haben wir ja gerade aus den selben Gründen ein umfangreiches Refactoring durchgeführt in der aktuellen Entwicklerversion, da er langsam aber sicher auf dem Weg in die Unwartbarkeit war. Du siehst also, dass wir schon dafür Sorgen, dass wir uns das Leben nicht allzu schwer machen ;-)

[Chris M.]

Ich hatte mir dabei mal kurz den PHP Quelltext angesehen. Ich bin beeindruckt, dass ihr in diesem Stiel ein ganzes Projekt am laufen habt.
Wenn ich an dieser Stelle einen wirklich nett gemeinten Tipp loswerden darf: trennt unbedingt Logik von Code.

Ja, beim PHP Code ist noch viel gewachsen. Der Code Check ist da relativ übersichtlich und wartungsarm, der Manager ist aber inzwischen ein Graus. Gibt daher auch schon ein Issue dafür : https://github.com/CometVisu/CometVisu/issues/722

[Brn]

Ok ich muss mir das Ganze wohl nochmal unter openHAB ansehen.

Gitb es eigentlich einen Grund, warum man bei einem vermeidlichen Validierungsfehler sich die Seite trotzdem nicht anzeigen lassen kann?
Gerade hinsichtlich der Include-Thematik, wenn die Includierungsfehler eigentlich gar keine Fehler sind wäre es praktisch, wenn man den Check deaktivieren kann.

//Edit: ich habe auch noch eine Frage zum Layout: soll sich das so verhalten wie bei Bootstrap?
ich frage, weil die Viso aus der Angabe colspan=2 ein style="width: 66.6667% macht, obwohl nach meinem Verständnis der Wert eigentlich bei 16.6667 liegen sollte. Oder?

[Chris M.]

Gitb es eigentlich einen Grund, warum man bei einem vermeidlichen Validierungsfehler sich die Seite trotzdem nicht anzeigen lassen kann?

Eine nicht valide XML erzeugt ein undefiniertes Verhalten. Unsere Lösung nichts anzuzeigen halte ich da für ganz vernünftig, es hätte ja auch eine weitere Nadel in der nächstbesten Voodoo-Puppe sein können...

Ganz praktisch: mit undefiniertem Zeugs umzugehen und eine Meinung zu interpretieren ist deutlich aufwändiger als ganz sauber nichts zu zeigen und den Anwender eine Hilfe bzgl. seinem Fehler zu geben.

Gerade hinsichtlich der Include-Thematik, wenn die Includierungsfehler eigentlich gar keine Fehler sind wäre es praktisch, wenn man den Check deaktivieren kann.

Die Anzeige / der Check mit Includes hat's übrigens inzwischen schon fast in den Code geschafft. Es muss nur noch eine kleine Inkompatibilität gefixt werden.

//Edit: ich habe auch noch eine Frage zum Layout: soll sich das so verhalten wie bei Bootstrap?
ich frage, weil die Viso aus der Angabe colspan=2 ein style="width: 66.6667% macht, obwohl nach meinem Verständnis der Wert eigentlich bei 16.6667 liegen sollte. Oder?

Grundsätzlich sollte colspan=2 ein 2/12 = 16,66...% ergeben.
Aber wenn ein colspan in einer Group mit eigenem colspan gesetzt wird, dann wird's etwas komplizierter. In einer Group mit colspan=3 wäre 66,66...% durchaus zu erwarten.

[Brn]

Aber wenn ein colspan in einer Group mit eigenem colspan gesetzt wird, dann wird's etwas komplizierter. In einer Group mit colspan=3 wäre 66,66...% durchaus zu erwarten.

Ich dachte das Colspan bezieht sich immer auf den aktuellen Kontext und ist nicht absolut zu lesen?!

Ich habe tatsächlich so eine Situation. Mein Bildschirm wird in 2 Gruppen geteilt, mit je colspan=6
Innerhalb einer Gruppe sollen in der 1. Zeile eine langer Block zu sehen sein und 3 Kleine. Ich hatte also das so gebaut (nicht maßstabsgetreu :-D)
|-------------col6----------|-------------col6----------|
|---col6--|-c2-|-c2-|-c2-|---col6--|-c2-|-c2-|-c2-|
|-----------------------------|-----------------------------|

Nach meinem Verständnis habe ich innerhalb eines col6 Blocks wieder 2 Teileinheiten. Dann müsste ein c2 doch effektiv 16,6% vom Elternelement sein.
Oder habe ich da was falsch verstanden?

Die Anzeige / der Check mit Includes hat's übrigens inzwischen schon fast in den Code geschafft. Es muss nur noch eine kleine Inkompatibilität gefixt werden.

Da bin ich hochgradig gespannt drauf! :-)