Aktuelle CV Version

[chrisper]

Ich glaube, es sind die PageJump-Elemente in der NavBar, nicht die NavBar selbst.

[Brn]

Ich habe dazu mal in ein Beispiel geschaut. Dort werden Colspan Werte mit nicht ganzen Zahlen genutzt.
http://cometvisu.org/CometVisu/de/la...l_haegar80.xml
Nach meinem Wissen unterstützt Bootstrap gar keinen colspan mit nicht-ganzen Zahlen.

Wenn ich nun meine Menü-Icons mit colspan=1 versehe ergibt sich die Situation, dass ich im Handy-Layout (400x817 pixel) die ersten 4 icons sehe und der Rest von rechts rein gescrollt werden muss. Ich hätte jetzt erwartet, dass 12 Elemente angezeigt werden oder zumindest umgebrochen wird!?
...oder ist das genau so gewollt? Dann würde mir ein Icon fehlen, dass mich darauf hinweist, dass das Menü rechts noch weiter geht.
menue.jpg



Btw: gibt es schon eine Idee zum Thema Caching von Dateien, die man mittels <include> einbindet?
Ich habe es jetzt mit 3 Browsern getestet und ist immer so, dass die inkludierte Datei nur 1x geladen wird. Möchte ich darin etwas ändern akzeptiert der Browser das nur, wenn ich auch den Namen ändere. Der alte Dateiname der Unterseite (config/kueche.xml) ist dann bis auf weiteres entwertet, denn er der Server liefert vehement immer den Content zu einer XML Datei aus, den erst zum ersten mal dort gefunden hat.

:-/

[chrisper]

Scrollen muss ich auch. Ob es anders auch geht hab ich mir noch nicht überlegt. Zum Thema include kann ich nichts sagen weil ich es nicht verwende. Bei mir sieht die navbar so aus (Auszug):

[COLOR=#0000FF]<[COLOR=#808000]navbar[/COLOR] [COLOR=#800080]position[/COLOR]=[COLOR=#FF00FF]"top"[/COLOR] [COLOR=#800080]dynamic[/COLOR]=[COLOR=#FF00FF]"true"[/COLOR]>[/COLOR]
[COLOR=#0000FF]  <[COLOR=#808000]group[/COLOR] [COLOR=#800080]name[/COLOR]=[COLOR=#FF00FF]"EG"[/COLOR]>[/COLOR]
    [COLOR=#0000FF]<[COLOR=#808000]layout[/COLOR] [COLOR=#800080]colspan[/COLOR]=[COLOR=#FF00FF]"3"[/COLOR] [COLOR=#800080]colspan-m[/COLOR]=[COLOR=#FF00FF]"6"[/COLOR] [COLOR=#800080]colspan-s[/COLOR]=[COLOR=#FF00FF]"9"[/COLOR]/>[/COLOR]
    [COLOR=#0000FF]<[COLOR=#808000]pagejump[/COLOR] [COLOR=#800080]target[/COLOR]=[COLOR=#FF00FF]"Wohnzimmer"[/COLOR]>[/COLOR]
      [COLOR=#0000FF]<[COLOR=#808000]layout[/COLOR] [COLOR=#800080]colspan[/COLOR]=[COLOR=#FF00FF]"0.5"[/COLOR] [COLOR=#800080]colspan-m[/COLOR]=[COLOR=#FF00FF]"1"[/COLOR] [COLOR=#800080]colspan-s[/COLOR]=[COLOR=#FF00FF]"1.5"[/COLOR]/>[/COLOR]
      [COLOR=#0000FF]<[COLOR=#808000]label[/COLOR]>[/COLOR]
        [COLOR=#0000FF]<[COLOR=#808000]icon[/COLOR] [COLOR=#800080]name[/COLOR]=[COLOR=#FF00FF]"it_television"[/COLOR]/>[/COLOR]
      [COLOR=#0000FF]</[COLOR=#808000]label[/COLOR]>[/COLOR]
    [COLOR=#0000FF]</[COLOR=#808000]pagejump[/COLOR]>[/COLOR]

[Chris M.]

Ich habe dazu mal in ein Beispiel geschaut. Dort werden Colspan Werte mit nicht ganzen Zahlen genutzt.
[...]
Nach meinem Wissen unterstützt Bootstrap gar keinen colspan mit nicht-ganzen Zahlen.

Ich habe mich eigentlich immer gegen die nicht ganzen Zahlen gewehrt, da es für mich nicht sauber ist.
Gerade im Zusammenhang mit dem Metal-Design werden die aber öfters verwendet und ich befürchte wir werden von denen nicht mehr weg kommen ohne einige Installationen kaputt zu machen.

Btw: gibt es schon eine Idee zum Thema Caching von Dateien, die man mittels <include> einbindet?
Ich habe es jetzt mit 3 Browsern getestet und ist immer so, dass die inkludierte Datei nur 1x geladen wird. Möchte ich darin etwas ändern akzeptiert der Browser das nur, wenn ich auch den Namen ändere. Der alte Dateiname der Unterseite (config/kueche.xml) ist dann bis auf weiteres entwertet, denn er der Server liefert vehement immer den Content zu einer XML Datei aus, den erst zum ersten mal dort gefunden hat.

Bei den Include-Dateien kann es durchaus sein, dass das Caching noch nicht optimal umgesetzt ist.
Um ein neues Laden zu erzwingen ohne den Browser-Cache zu leeren kann man mal versuchen da an den Pfad einen Zeitstempel anzuhängen (also z.B. "abc.xml?ts=180906221223").
Ansonsten hätte ich eher befüchtet, dass diese Dateien zu oft als zu selten geladen werden...

Mit der neuesten CometVisu Version die aktuell in Entwicklung ist kann es hier durchaus eine Änderung im Verhalten geben, da hier einiges hinter den Kulissen geändert wurde.
=> Welche Version nutzt Du, was ist das erwartete und was das reale Verhalten?

[peuter]

Also neue Build gibt es immer nach einer Änderung im Source-Code, der letzte ist 2 Tage alt. Die komplette Liste ist hier: https://bintray.com/cometvisu/CometV...ightlies#files

Zu den Navbars: Dass das auf schmalen Bildschirmen in der Top-/Bottom-Navbar vertikal scrollbar wird ist Absicht. Da irgendwas zusammenzuquetschen macht es unbedienbar und die Navbar umzubrechen finde ich auch unschön. Dann hat man auf dem kleinen Bildschirm erstmal fast nur die Nabvar und muss nach unten scrollen um den Rest von "Startbildschirm" zu sehen. Noch ein Hinweis: Meine Navbar (oben) besteht aus 12 Pagejumps mit colspan="0", das bewirkt, dass die Pagejumps nur den Platz (in der Breite) einnehmen, den sie wirklich benötigen. Da muss mann dann auch nicht mit krummen Werten in den colspans hantieren, die auf jedem Bildschirm doch wieder anders aussehen.

Die Entwicklerversion bringt einen XML-Texteditor mit, den kann man über die manager.php aufrufen (direkt neben den "normalen"-Editor Link). Der macht auch gleich eine Validierung gegen die Schema-Datei. Aber innerhalb der Includes wird die Schema-Validierung nicht funktionieren. Der dort benutzte Editor (der komplett im Browser läuft) ist der selbe der innerhalb von Visual Studio Code läuft.

Un zu guter letzt zu Thema includes + cache. Also grundsätzlich funktioniert das schon. Ich habe es gerade nochmal getestet. Ich kann auch innerhalb der includeten Datei Änderungen machen und sehe die trotz aktiviertem Cache, wenn ich neu lade. Daher kann ich den Fehler leider nicht reproduzieren. Ich vermute da ein Timing problem. Dass z.b. noch nicht alle include-Dateien geladen worden sind, bevor die Cache Behandlung greift. Ich könnte da auch einen PR machen, aber der würde auf reiner Vermutung basieren und komplett ungetestet sein. Weiß nicht ob sowas sinnvoll ist.

Ansonsten kannst Du nach jeder Änderung über einen URL-Parameter den Cache selbst löschen: (http://cometvisu.org/CometVisu/de/cu...ing-aktivieren) => ?enableCache=invalid

[Brn]

Hey,
zunächst danke für die ganzen Feedbacks.

=> Welche Version nutzt Du, was ist das erwartete und was das reale Verhalten?

Ich habe mich eigentlich immer gegen die nicht ganzen Zahlen gewehrt, da es für mich nicht sauber ist.

Ich persönlich finde es auch verwirrend, da die Begrifflichkeit im Bootstrap Umfeld intensiv genutzt wird und dort (sicher aus gutem Grund) nicht ganze Zahlen für colspans nicht zulässig sind.

=> Welche Version nutzt Du, was ist das erwartete und was das reale Verhalten?

0.11.0
Ich hätte erwartet, dass geänderte Inhalte beim nächsten refresh der Seite sichtbar sind.
In der Praxis: Entweder, das mit Klick auf den Menüpunkt "Küche", das dazugehörige <include> file geladen wird. Also Lazy-Loading beim sichtbar-machen. Oder, dass beim Laden der Seite immer alle include-Dateien geladen werden, auch wenn man sie nicht sieht. Die XML Daten sind in dem Umfeld nicht so groß und können per HTTP sogar komprimiert werden....
..wobei das Komprimieren beim Einsatz eines Raspi sicher länger dauert, als das Ausliefern dieser 50kByte Datei.
Wenn man seine Visu von unterwegs abruft ist das mit dem "Vorausladen" natürlich ein Problem.


Das mit dem zusätzlichen ts-Parameter ist sicher erstmal eine Übergangslösung, aber so richtig ideal dann doch nicht.

Dass das auf schmalen Bildschirmen in der Top-/Bottom-Navbar vertikal scrollbar wird ist Absicht. Da irgendwas zusammenzuquetschen macht es unbedienbar und die Navbar umzubrechen finde ich auch unschön.

Ich finde das Feature gar nicht schlecht. Man muss halt nur wissen, was geht. WYSIWYG ist es halt nicht.

Die Entwicklerversion bringt einen XML-Texteditor mit, den kann man über die manager.php aufrufen (direkt neben den "normalen"-Editor Link). Der macht auch gleich eine Validierung gegen die Schema-Datei. Aber innerhalb der Includes wird die Schema-Validierung nicht funktionieren. Der dort benutzte Editor (der komplett im Browser läuft) ist der selbe der innerhalb von Visual Studio Code läuft.

Ah, klingt gut. funktioniert aber leider nicht: das Browserfenster bleibt schwarz

cometvisu/node_modules/monaco-editor/min/vs/editor/editor.main.nls.en.js 404 (Not Found)
e.load @ loader.js:17
e.load @ loader.js:16
i @ loader.js:30
s._loadModule @ loader.js:30
s._resolve @ loader.js:32
s.defineModule @ loader.js:26
s._relativeRequire @ loader.js:27
n @ loader.js:30
e.load @ editor.main.js:12
s._loadPluginDependency @ loader.js:31
s._resolve @ loader.js:32
s.defineModule @ loader.js:26
o @ loader.js:34
(anonymous) @ editor.main.js:824
(anonymous) @ editor.main.js:2002

tatsächlich fehlt die ...en.js

Wenn der Browser in deutsch läuft, klappt es.

Dafür gibt koreanisch und andere Sprachen...

. Ich könnte da auch einen PR machen, aber der würde auf reiner Vermutung basieren und komplett ungetestet sein. Weiß nicht ob sowas sinnvoll ist.

Hmm... das kann ich leider auch nicht beurteilen. `?enableCache=invalid` bringt leider keinen Unterschied.


//Edit: und noch ein Punkt, der mir bei der Benutzung des neuen Build vom 09.09.18 aufgefallen ist: unter config ist kein backup Verzeichnis und beim erstmaligen Speichern wird auch kein Verzeichnis implizit angelegt.

[Brn]

Nochmal eine Frage zum aktuellen Bild: ich habe aktualisiert auf das Build CometVisu-0.11.0-dev-20180907020543.zip und jetzt kommt folgende Meldung:

http://cvhost/cometvisu/script/cv-webkit.1fdd6c7d211c.js 404 (Not Found)
qx.bom.request.Script.prototype.send() @ cv-webkit.js:213
(anonymous) @ cv-webkit.js:213
setTimeout (async)
q @ cv-webkit.js:213
qx.io.part.Package.prototype.__gj() @ cv-webkit.js:213
qx.io.part.Package.prototype.loadClosure() @ cv-webkit.js:213
qx.io.part.ClosurePart.prototype.load() @ cv-webkit.js:213
qx.Part.prototype.require() @ cv-webkit.js:213
qx.io.PartLoader.prototype.require() @ cv-webkit.js:213
qx.io.PartLoader.require() @ cv-webkit.js:213
cv.TemplateEngine.prototype.loadParts() @ cv-webkit.js:213
cv.Application.prototype.loadPlugins() @ cv-webkit.js:213
cv.Application.prototype.bootstrap() @ cv-webkit.js:213
cv.util.ConfigLoader.prototype._checkQueue() @ cv-webkit.js:213
(anonymous) @ cv-webkit.js:213
h @ cv-webkit.js:213
qx.event.dispatch.Direct.prototype.dispatchEvent() @ cv-webkit.js:213
qx.event.Manager.prototype.dispatchEvent() @ cv-webkit.js:213
qx.event.Registration.__de() @ cv-webkit.js:213
qx.event.Registration.fireEvent() @ cv-webkit.js:213
qx.core.Object.prototype.fireEvent() @ cv-webkit.js:213
qx.io.request.AbstractRequest.prototype._fireStatefulEvent() @ cv-webkit.js:213
qx.io.request.AbstractRequest.prototype.__dX() @ cv-webkit.js:213
qx.io.request.AbstractRequest.prototype._onReadyStateChange() @ cv-webkit.js:213
(anonymous) @ cv-webkit.js:213
qx.bom.request.Xhr.prototype._emit() @ cv-webkit.js:213
qx.bom.request.Xhr.prototype.__er() @ cv-webkit.js:213
qx.bom.request.Xhr.prototype.__eq() @ cv-webkit.js:213
(anonymous) @ cv-webkit.js:213
(anonymous) @ cv-webkit.js:213
XMLHttpRequest.send (async)
qx.bom.request.Xhr.prototype.send() @ cv-webkit.js:213
qx.io.request.AbstractRequest.prototype.send() @ cv-webkit.js:213
cv.util.ConfigLoader.prototype.load() @ cv-webkit.js:213
(anonymous) @ cv-webkit.js:213
qx.bom.Lifecycle.onReady() @ cv-webkit.js:213
cv.Application.prototype.__fi() @ cv-webkit.js:213
cv.Application.prototype.main() @ cv-webkit.js:213
qx.core.Init.ready() @ cv-webkit.js:213
qx.event.dispatch.Direct.prototype.dispatchEvent() @ cv-webkit.js:213
qx.event.Manager.prototype.dispatchEvent() @ cv-webkit.js:213
qx.event.Registration.__de() @ cv-webkit.js:213
qx.event.Registration.fireEvent() @ cv-webkit.js:213
qx.event.handler.Application.prototype.__ke() @ cv-webkit.js:213
qx.event.handler.Application.prototype.__kf() @ cv-webkit.js:213
(anonymous) @ cv-webkit.js:213
qx.event.handler.Application.prototype._onNativeLoad() @ cv-webkit.js:213
(anonymous) @ cv-webkit.js:213
load (async)
qx.bom.Event.addNativeListener() @ cv-webkit.js:213
qx.event.handler.Application.prototype._initObserver() @ cv-webkit.js:213
qx.event.handler.Application.constructor() @ cv-webkit.js:213
cJ @ cv-webkit.js:213
qx.event.Manager.prototype.getHandler() @ cv-webkit.js:213
qx.event.Manager.prototype.findHandler() @ cv-webkit.js:213
qx.event.Manager.prototype.__da() @ cv-webkit.js:213
qx.event.Manager.prototype.addListener() @ cv-webkit.js:213
qx.event.Registration.addListener() @ cv-webkit.js:213
defer @ cv-webkit.js:213
(anonymous) @ cv-webkit.js:213
qx.Bootstrap.addPendingDefer() @ cv-webkit.js:213
qx.Class.define() @ cv-webkit.js:213
(anonymous) @ cv-webkit.js:213
(anonymous) @ cv-webkit.js:213

...und es wird nun statt meiner Viso Seite lediglich ein leerer Hintergrund angezeigt.
Im Verzeichnis .../cometvisu/script/ gibt es übrigens diverse cv-webkit.js Dateien. Allerdings keine mit dem o.g. Hash.

//Edit: noch ein Nachtrag: da das Build vom 07.09 gar nicht läuft, hatte ich noch mal auf das Build vom 05.08. zurückgegriffen. Dort habe ich ein weiteres Problem beim <include>. Wenn ich einen größeren XML Block aus der Visu Datei entnehme und in eine sperate Datei schiebe, kommt beim Laden der Haupt-Datei die Meldung:
"Fehler in der Konfigurations-Datei. ungültige Konfigurations-Datei Bitte prüfen!"
Wenn ich dann prüfe sagt mir check_config ...is valid XML.

Habt ihr dazu irgendwelche Ideen?

[peuter]

Klingt irgendwie so als ob Dein Browser noch eine alte index.html im Cache hätte, die dann auf eine nicht mehr existierende JS-Datei verweist. Vielleicht reicht ein Reload mit Strg+F5, ansonsten Browser-Cache leeren.

[Brn]

Strg+F5 mache ich eigentlich ausschließlich. Ich hatte dann die developer Tools geöffnet und "Disable Cache" aktiviert. Das hat dann geholfen.
Das mit dem Include ist trotzdem noch so ein Ding. Kann man den XML Checker nicht Rekursiv auch die inkludierten Dateien prüfen lassen, damit ich bspw. eine Vorstellung bekomme, was ihn stört?

Ich hatte im Rahmen des Try& Error meinen Block der Include-Datei immer weiter zusammen gedampft, bis ich festgestellt habe, dass z.B. ein Layout-Tag in der ersten Zeile der eingebundenen Datei ein Grund für die Fehlermeldung verantwortlich war. Irgendwo steckt aber auch noch was anderes, woran er sich stört.
Bei größeren XML Blöcken wird man nicht froh, wenn man mittels Try&Error alle Versuche durchprobieren muss um den Tag zu erkennen, der dann stört.

[peuter]

Verteilte XML-Dateien gegen ein Schema zu validieren ist eigentlich nur möglich, wenn man vorher eine große XML-Datei erzeugt die alles enthält und diese dann prüft. Da hat man dann aber immer noch das Problem, dass die Zeilenangaben der Fehler nicht mehr stimmt. Das müsste man dann aufwändig wieder zurückrechnen. Die inkludierten Dateien kann man nicht einzeln für sich prüfen.

Ich kann vom benutzen der Includes eigentlich nur abraten, aus o.g. Gründen. Wenn man einen brauchbaren XML-Editor hat der selbst gegen ein Schema validieren kann hat man da deutlich weniger Probleme. Wenn der dann auch noch eine vernünftige GUI mitbringt, mit dem man z.B. XML-Teilbäume einklappen kann, dann gibts auch keinen Grund mehr da irgendwas zu partitionieren.

[Brn]

Verteilte XML-Dateien gegen ein Schema zu validieren ist eigentlich nur möglich, wenn man vorher eine große XML-Datei erzeugt die alles enthält und diese dann prüft. Da hat man dann aber immer noch das Problem, dass die Zeilenangaben der Fehler nicht mehr stimmt. Das müsste man dann aufwändig wieder zurückrechnen. Die inkludierten Dateien kann man nicht einzeln für sich prüfen.

Ich kann vom benutzen der Includes eigentlich nur abraten, aus o.g. Gründen. Wenn man einen brauchbaren XML-Editor hat der selbst gegen ein Schema validieren kann hat man da deutlich weniger Probleme. Wenn der dann auch noch eine vernünftige GUI mitbringt, mit dem man z.B. XML-Teilbäume einklappen kann, dann gibts auch keinen Grund mehr da irgendwas zu partitionieren.

Das verstehe ich. Aber allein das Ausgeben der Zeile selber würde bei der Fehlersuche schon helfen...
...so lange des XML von der Visu GUI nicht wieder in eine Zeile gematscht wird. ;-)

Derzeit hat meine Konfig 493 Zeilen und ich habe keine Ahnung, wo der Fehler ist. Zumal die Fehler durchaus auch valides XML sein können, aber im Fall eines include ggf. nicht akzeptiert werden. Wie z.B. der <layout> block, der in der Hauptdatei als valide galt, aber als er in der inkludierten Datei eingebunden wurde dazu führte, dass der Fehler aufpoppte.

Wenn der dann auch noch eine vernünftige GUI mitbringt, mit dem man z.B. XML-Teilbäume einklappen kann, dann gibts auch keinen Grund mehr da irgendwas zu partitionieren.

Das mit dem Einklappen der Teilbäume ist sicher ein großer Vorteil. Trotzdem wird die Problemsuche immer schwieriger, je drößer die Datei ist. Wenn man dann noch auf der Konsole arbeitet ist es mit leistungsfähigen XML Editoren schnell ein Problem und eine X-Anwendung tunneln geht auch nur, wenn das lokale System da mitspielt, was nicht immer der Fall ist.

Alles in allem finde ich eine Unterstützung der Fragmentierung der Konfig ein sehr wichtiges Feature.
Alternativ könnte man für jede Unterseite eine eigene Visu - Konfig anlegen. Aber dann müsste man die Pluginsdefinitionen und das Mapping immer wieder neu definieren. Auch das Menü müsste in jeder Datei stehen.
Zudem unterstützt das pagejump Widget nach meinem Wissen weder die Unterstützung von URLs (also Links zu http://ohhost/cometvisu/?config=seite2) noch die Angabe einer Art "Unterseite"" <pagejump target="visiu_config_seite2.xml">

Die inkludierten Dateien kann man nicht einzeln für sich prüfen.

Eine Möglichkeit wäre, dass die inkludierten Dateien einfach immer dem Schema entsprechen müssen. So dass sie entweder inkludiert werden können oder auch alleine aufgerufen werden können.


Im Moment ist es einfach nur verwirrend, warum das <include> feature manchmal geht und manchmal einen Fehler wirft und ich merke tatsächlich, dass die Erstellung der Konfig anstrengender wird.

[peuter]

Derzeit hat meine Konfig 493 Zeilen und ich habe keine Ahnung, wo der Fehler ist. Zumal die Fehler durchaus auch valides XML sein können, aber im Fall eines include ggf. nicht akzeptiert werden. Wie z.B. der <layout> block, der in der Hauptdatei als valide galt, aber als er in der inkludierten Datei eingebunden wurde dazu führte, dass der Fehler aufpoppte.

Hast Du da mal ein Beispiel zu, denn das sollte nicht so sein. Die Validität darf sich nicht ändern, wenn man den selben Code in eine include Datei auslagert.

Das mit dem Einklappen der Teilbäume ist sicher ein großer Vorteil. Trotzdem wird die Problemsuche immer schwieriger, je drößer die Datei ist. Wenn man dann noch auf der Konsole arbeitet ist es mit leistungsfähigen XML Editoren schnell ein Problem und eine X-Anwendung tunneln geht auch nur, wenn das lokale System da mitspielt, was nicht immer der Fall ist.

In der Konsole wird das natürlich schnell unübersichtlich, ich meinte hier "richtige" Editoren mit GUI (z.b. Visual Studio Code). Dazu muss man sich die Datei aber entweder immer auf seinen Arbeitsrechner kopieren und dann wieder zurück, oder eine Netzwerkfreigabe für den Config-Ordner einrichten. X-Anwendung tunneln ist da eher keine gute Option.

Alternativ könnte man für jede Unterseite eine eigene Visu - Konfig anlegen. Aber dann müsste man die Pluginsdefinitionen und das Mapping immer wieder neu definieren. Auch das Menü müsste in jeder Datei stehen.
Zudem unterstützt das pagejump Widget nach meinem Wissen weder die Unterstützung von URLs (also Links zu http://ohhost/cometvisu/?config=seite2) noch die Angabe einer Art "Unterseite"" <pagejump target="visiu_config_seite2.xml">

Sowas ist auch nicht angedacht, da es zu einem kompletten Neuladen der Visu im Browser führen würde. Das will ja keiner.

Eine Möglichkeit wäre, dass die inkludierten Dateien einfach immer dem Schema entsprechen müssen. So dass sie entweder inkludiert werden können oder auch alleine aufgerufen werden können.

Auch schwierig, weil eine valide XML-Datei einen Header haben muss (in dem z.B. das Schema steht). Die wäre dann aber nicht mehr "einbettbar" weil dazu der Header erst wieder raus müsste. Würde die Möglichkeiten, wo man die Config-Dateien "trennen" kann auch dramatisch einschränken.

Im Moment ist es einfach nur verwirrend, warum das <include> feature manchmal geht und manchmal einen Fehler wirft und ich merke tatsächlich, dass die Erstellung der Konfig anstrengender wird.

Wie schon gesagt, sollte der Code unabhängig davon ob er jetzt in einer Datei oder in mehreren steht zu dem gleichen Ergebnis in Sachen Validität kommen. Ist das nicht der Fall, klingt das eher nach einem Bug.

[peuter]

Brn Kannst Du mal Deine check_config.php mit dem Inhalt aus der angehängten check_config.txt austauschen und testen, ob es die Fehler in den inkludierten Dateien findet (die fügt alle zu einer großen ganzen zusammen und prüft die, wenn ein Fehler in einer include-Datei gefunden wurde, sollte da auch der Dateiname + Zeilennummer bei stehen).

Zwei Hinweise:
1. Funktioniert nur mit "richtigem" PHP, also nicht, wenn die Visu von openHAB ausgeliefert wird.
2. Ist einigermaßen schnell zusammengestrickt, d.h. Probleme sind zu erwarten (z.B. dass die Zeilennummer nicht ganz stimmen)

[Brn]

Danke für die Rückmeldung.

1. Funktioniert nur mit "richtigem" PHP, also nicht, wenn die Visu von openHAB ausgeliefert wird.

Tatsächlich wird bei mir ausschließlich über openHab ausgeliefert. Habe keinen autarken Webserver laufen.
Geht das vielleicht auch über die Konsole?

Aber als Beispiel... ich entnehme aus der originalen Datei folgendes:

              <layout colspan="12"/>
                <group name="Flur" nowidget="true">
                    <layout colspan="12"/>
                    <info>
                        <layout colspan="2"/>
                        <label>
                            <icon name="light_led_stripe"/>
                        </label>
                        <address transform="OH:dimmer">ledDiele</address>
                    </info>
                </group>

..und packe das in eine Datei, die ich mittels <include> Einbinde und es kommt beim Laden der Hauptseite folgende Meldung:
"Ungültige Konfigurations-Datei!
Bitte prüfen!"

In dem Moment, wenn ich in der inkludieren Datei die erste <layout>-Zeile entferne, funktioniert alles.

[peuter]

Da die check_config.php HTML-Code ausgibt, wird das auf der Konsole nicht besonders gut lesbar sein. Das Problem mit dem <layout> in der include-Datei würde davon sowieso nicht gefunden, da das valides XML ist. Das Problem ist hier, dass der XML-Parser der im Browser eingebaut ist, den XML nicht parsen kann, wenn der nicht einen einzelnes "Wurzel"-Element hat (ohne <layout> wäre das in Deinem Beispiel <group>). Wenn das nicht der Fall ist, gibt der Parser einen Fehler zurück.
Das ist ein Bug und die Lösung besteht darin, zunächst die Include-Datei als reinen Text zu laden, da dann z.B. ein <root>...</root> drumzupacken, dass dann zu parsen usw.

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