cometvisu-client.js überschreiben ohne hardcodierten UrlPrefix?

[NetFritz]

Hallo
Ja OH kann vieles lösen, es gibt aber Leute die mögen kein Java.
Ich habe es auch mal mit OH probiert um eine Wago-SPS per Modbus anzubinden.
Ich wollte das universell mit Rules lösen, das man nur die Item anlegen muss.
Ist mir in einer Richtung auch gelungen, die andere Richtung wollte auf die Grups nicht reagieren.
Vielleicht ist mein Beispiel aus den Post 44 auch dazu nicht geeignet warum man in einer CV mehre
Backend gebrauchen kann.

@tuxedo
Theoretisch wäre es aber möglich die Situation über den Namespace "OH:" zu lösen.

Dann sollte man das auch machen.
Gruß NetFritz

[jolt]

Kann ich mich nicht so recht mit anfreunden, weils wirklich ein Hack ist. Zu sagen Jetty-Server = openHAB ist mir ein bischen zu unpräzise, auch wenns in 99% der Fälle stimmen mag. Wer weiß was die Zukunft bringt und openHAB1 von openHAB2 zu unterscheiden geht damit nicht, da muss man dann schon wieder zusätzlich nach dem neuen Header suchen (den die aktuelle Version von openHAB2 noch garnicht liefert). Lass mich erstmal gucken obs keinen "richtigen" Weg für openHAB1 gibt, bevor wir zu solchen Hacks greifen ;-)

Natürlich kommt der Hack nur an den Start wenn per Header keine URL geschickt wurde und das XML nichts weiter vorgibt. Auch würde ich erwarten das alle zukünftigen Backend dafür sorgen einen entsprechenden Header zu schicken. Dann würde es also nur schief gehen wenn auf dem Wiregate plötzlich Jetty zum Einsatz kommt. Das ist sicher ein Risiko das ich eingehen würde

Anyway, mir ging es ja eigentlich erstmal nur um die Betrachtung ob es überhaupt grundsätzlich möglich ist die OH Situation zu erkennen. Quasi einen Plan B, falls es sich nicht noch anders lösen lässt.

Was ich bei meinem letzten Post ganz vergessen habe. Wann soll der zusätzliche Header denn ausgeliefert werden? Bei Auslieferung der index.html + JS Dateien der CometVisu macht es keinen Sinn, weil es ja dann noch nicht ausgelesen werden kann. Meines Erachtens macht das nur Sinn bei Auslieferung einer visu_config*.xml. Denn da wirds ja dann auch gebraucht. Klar kann der Server das einfach immer mitliefern, an anderen Stellen wirds dann halt ignoriert, aber wenn wir für dieses neue Backend-Feature Anforderungen definieren + dokumentieren würde ich sagen, das das mit den Configs geliefert werden muss.

Zugriff auf den Header haben wir nur bei per Ajax angeforderten Ressourcen. Ich habe das in meinem Hack oben beim Lesen der Config gemacht. So würde ich das auch spezifizieren wollen, bei allen anderen Responses kann der Header zwar mit übertragen werden, wird dann aber schlicht ignoriert.

[tuxedo]

Zugriff auf den Header haben wir nur bei per Ajax angeforderten Ressourcen. Ich habe das in meinem Hack oben beim Lesen der Config gemacht. So würde ich das auch spezifizieren wollen, bei allen anderen Responses kann der Header zwar mit übertragen werden, wird dann aber schlicht ignoriert.

Würde ja auch reichen. Aber zumindest auf Apache/Lighttpd Seite wäre es wohl zu umständlich (aber machbar) nur für die eine Ressource den Header auszuliefern. Von daher würd ichs auch so machen: Für die Config-Ressource vorraussetzen und beim Rest ignorieren.

Ja OH kann vieles lösen, es gibt aber Leute die mögen kein Java.

Dann mögen sie auch kein OH, OH2 und auch kein KAD. Bleibt nach heutigem Stand nur ein Backend übrig: knxd
Für Leute-die-kein-Java-mögen User wäre das also gar kein Usecase mit mehreren backends.

Dann sollte man das auch machen.

Nur weil etwas möglich ist, sollte man es nicht unbedingt gleich machen. Der Namespace war dazu gedacht mehrere Adress-Arten voneinander zu unterscheiden, und nicht direkt um das Backend zu selektieren. Dass man das damit indirekt auch machen könnte (wenn man es so implementieren würde) ist halt eine andere Sache.

[Chris M.]

Theoretisch wäre es aber möglich die Situation über den Namespace "OH:" zu lösen.

Das wäre aber ein Missbrauch des Namespace...

[Chris M.]

Ja OH kann vieles lösen, es gibt aber Leute die mögen kein Java.

Das schöne an der CV ist, dass die unabhängig von der Backend-Implementierung ist. D.h. egal ob man Java mag oder nicht - auf die CV hat das keinen Einfluss.

Dann mögen sie auch kein OH, OH2 und auch kein KAD. Bleibt nach heutigem Stand nur ein Backend übrig: knxd
Für Leute-die-kein-Java-mögen User wäre das also gar kein Usecase mit mehreren backends.

Es gibt bereits ein weiteres Kein-Java-dafür-gutes-C++-Backend. Ein paar Hinweise hab ich schon verstreut, für mehr muss ich aber noch ein paar Hausaufgaben machen...

[tuxedo]

Das wäre aber ein Missbrauch des Namespace...

ich möchte hervorheben, dass das "theoretisch" auch tatsächlich als "theoretisch" gemeint war und ich diese Lösung nicht gut heißen wollte/möchte.
Sehe keinen wirklichen Mehrwert oder tatsächlichen Usecase mehrere Backends simultan zu nutzen.

Es gibt bereits ein weiteres Kein-Java-dafür-gutes-C++-Backend. Ein paar Hinweise hab ich schon verstreut, für mehr muss ich aber noch ein paar Hausaufgaben machen...

*gespanntbin*