Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Hmm... Stimmt. Anscheinend hat der Browser die URL selber so codiert, dass keine Umlaute mehr drin sind.
Ich würde es mal so formulieren: der Browser stellt URLs mit kodierten Zeichen automatisch gut lesbar dar, verwendet sie aber im HTTP-Protokoll konform.
Dann verstehe ich aber nicht wo der Editor Probleme hat. Könnte es doch das Sonderzeichen ~ sein?
Dazu kann ich leider nichts sagen, da ich mich weder mit CV noch mit dem Editor beschäftige (sondern hier nur aus Interesse mitlese). Es könnte sein, dass es tatsächlich das ~ Zeichen ist, aber es wäre auch denkbar, dass in der Tat die Umlaute als solche eingesetzt wurden und dann die URLs effektiv invalide wurden.
Gruss, Othmar
EIB/KNX, VISU mit knxd + linknx + knxweb, Steuerbefehle via SMS und Email mit postfix + procmail
Hmm... Ich habe mal das ~ aus der URL entfernt um zu testen ob der Editor der CV diese als valide betrachtet und das Ergebniss ist negativ. Sehr seltsam. Wenn ich wüsste wo das her kommt. Die Umlaute habe ich auch mal entfernt und er mekkert immer noch. Hingegen funktioniert die URL für z.B. Wetzikon problemlos.
Vieleicht können sich die CV Entwikler das Verhalten erklären.
Tatsächlich konnte ich keinerlei Inhalt für das src-Attribut speichern unabhängig von den verwendeten Zeichen.
Ich war mal so frei und habe einen kleinen Fix im SVN eingespielt, mit dem es nun klappen sollte.
Nur am Rande: irgendwelche Umlaute in URLs sind mW keinesfalls valide, zumindest nicht in meiner Welt selbst wenn es dafür einen kranken Workaround gibt - muss immer escaped werden!
Der nächste fängt dann mit IDN-Domain-Namen an..
Theoretisch!! (Julian?) könnte man darüber nachdenken, beim speichern / vor dem validieren einen Escape über die URL drüberlaufen zu lassen..
Tatsächlich konnte ich keinerlei Inhalt für das src-Attribut speichern unabhängig von den verwendeten Zeichen.
Ich war mal so frei und habe einen kleinen Fix im SVN eingespielt, mit dem es nun klappen sollte.
Den Fix der Textarea verstehe ich (peinlicher Fehler).
Aber dass die Änderung des basetype von String auf AnyURI etwa gebracht haben soll kapier ich nicht: der Editor verwendet doch trotzdem noch die alte Validierungs-Regel...
Vieleicht können sich die CV Entwikler das Verhalten erklären.
Nein.
Da URLs mannigfaltig sein können, wird garnicht erst versucht groß zu validieren. Es wird nur geschaut, ob die Eingabe ein String ist, ohne weitere inhaltliche Überprüfung...
Ich teste gerade mal etwas... Mir kam es gestern so vor, als ob der Editor nach der ersten "invalieden" Adresse jede andere Adresse im selben Textfeld auch für invaliede hielt. Auch wenn plötzlich hinter dem Fenster mit der Fehlermeldung noch das Fenster mit "Config was saved" erschien...
@Michael: Danke für den fix. Den werde ich gleich mal bei mir testen
Ich habe gerade mal das SVN Update gemacht. Nun funktioniert die URL und auch das Problem mit der URL zur Audiodatei hat sich gelöst. *freu* Nun funktioniert auch: http://192.168.1.120/visu_svn/test.ogg
Aber dass die Änderung des basetype von String auf AnyURI etwa gebracht haben soll kapier ich nicht: der Editor verwendet doch trotzdem noch die alte Validierungs-Regel...
Das ist richtig, dieser Editor kann das (noch) nicht, aber wenn du die XML-Datei mit einem XML-Editor bearbeitest, dann macht es schon einen Unterschied.
warum wird denn eigentlich z.B. dem Info Element "Address" und "Label" einzeln angezeigt?
Rechts ist doch eigentlich genug Platz, um alle Eigentschaften anzuzeigen.
Man könnte -um es allen Recht zu machen- wenn man links "info" wählt, alle Eigenschaften anzeigen, und wenn man Adress oder Label wählt nur deren Eigenschaften.
Das Speichern schlägt hier übrigens noch immer fehl. Das sollten wir uns nochmal ansehen, oder?
Komisch ist ja, das die Datei geschrieben wird. Es kann also kein Rechte-Problem sein.
Worann kann es dann liegen? Gibt es Bibliotheken, die auf dem Server nötig sind?
warum wird denn eigentlich z.B. dem Info Element "Address" und "Label" einzeln angezeigt?
Rechts ist doch eigentlich genug Platz, um alle Eigentschaften anzuzeigen.
Weil Address und Label eigene Elemente mit eigenen Attributen/Eigenschaften sind.
Das Speichern schlägt hier übrigens noch immer fehl. Das sollten wir uns nochmal ansehen, oder?
Komisch ist ja, das die Datei geschrieben wird. Es kann also kein Rechte-Problem sein.
Worann kann es dann liegen? Gibt es Bibliotheken, die auf dem Server nötig sind?
Hast du ein Wiregate oder ein CG?
Welche PHP-Version ist installiert?
Funktioniert das Speichern mit dem alten Editor (Release-Version)?
Ich hab die save_config.php noch mal ergänzt, so dass sie eine Fehlermeldung wirft, wenn das empfangene JSON nicht vernünftig dekodiert werden konnte ... das sollte bei dir jetzt dafür sorgen, dass die Config nicht kaputtgespeichert wird.
Alternativ/ergänzend bitte noch mal aus dem Firebug die Antwort von save_config.php suchen und mitteilen (Firebug - Konsole - den POST-Request raussuchen - das Tab "Antwort" kopieren).
@Netzkind: Ist das für dich eigentlich zielführend, alle Bugs hier in diesem Thread zu sammeln, oder hättest du lieber Einträge im Bugtracker(SourceForge.net: Open Automation: Bugs
Den Bugtracker von Sourceforge mag ich nicht besonders. Da es aktuell vor allem ein hin-und-her bei Fehlern ist, finde ich es erst mal nicht verkehrt, das hier im Thread zu machen. Zumindest so lange wie ich noch regelmässig aktiv an der Entwicklung sitze
Aber wo finde ich eine Liste aller verfügbaren Flavours (hab nicht gesucht)?
Das wird schwierig, denn die Liste ist vom Design abhängig.
(Eine Liste gibt es noch nicht, ließe sich aber leicht anlegen. Bitte definiere wie es für Dich am geschicktesten ist, sollte halt im jeweiligen Design-Ordner liegen)
TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
Weil Address und Label eigene Elemente mit eigenen Attributen/Eigenschaften sind.
Aber das interessiert den User doch nicht ;-)
Praktischer wäre es, wenn alles auf einmal angezeigt wird, denn man will doch das ganze Objekt editieren
Hast du ein Wiregate oder ein CG?
Debian-Squeeze mit Paketen vom wiregate-repo --> CG-Artig.
Welche PHP-Version ist installiert?
Funktioniert das Speichern mit dem alten Editor (Release-Version)?
Code:
PHP 5.3.3-7+squeeze9 with Suhosin-Patch (cli) (built: May 9 2012 07:20:37)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH
Das Speichern funktioniert mit der Release-Version.
Ich hab die save_config.php noch mal ergänzt, so dass sie eine Fehlermeldung wirft, wenn das empfangene JSON nicht vernünftig dekodiert werden konnte ... das sollte bei dir jetzt dafür sorgen, dass die Config nicht kaputtgespeichert wird.
Jepp:
Code:
configuration could not be saved, server responded with 'configuration-data could not be decoded
Wurde auch nicht berschrieben. Soweit eine Verbesserung.
Alternativ/ergänzend bitte noch mal aus dem Firebug die Antwort von save_config.php suchen und mitteilen (Firebug - Konsole - den POST-Request raussuchen - das Tab "Antwort" kopieren).
Code:
{"success":false,"message":"configuration-data could not be decoded"}
Das wird schwierig, denn die Liste ist vom Design abhängig.
(Eine Liste gibt es noch nicht, ließe sich aber leicht anlegen. Bitte definiere wie es für Dich am geschicktesten ist, sollte halt im jeweiligen Design-Ordner liegen)
Dann wird es schwierig.
Könnte man irgendwie in einen dataprovider reinklöppeln, auch dass der sich aus der Config raussucht welches Design der User grade gewählt hat - fängt aber dann an zu brechen, sobald der User das Design wechselt.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar