Editor-Entwicklung

[ZeitlerW]

Hallo Julian,

wenn wir gerade bei Kleinigkeiten sind :
Vielleicht könnte man die Auto - Vervollständigung auch auch die Icons erweitern:
Dazu müßte die ./lib/iconhandler.js geparst werden und die dynamischen Icons herausgefunden werden (z.Zt ab Zeile 130).

Soweit die Theorie, leider kann ich magels js - Kenntnissen nicht wirklich etwas dazu beitragen .

vG
Wolfgang

[Chris M.]

Vielleicht könnte man die Auto - Vervollständigung auch auch die Icons erweitern:
Dazu müßte die ./lib/iconhandler.js geparst werden und die dynamischen Icons herausgefunden werden (z.Zt ab Zeile 130).

Da muss nix geparst werden, einfach die Datei mit einbinden und nutzen - der Iconhandler ist im Grunde nur eine kleine Datenbank zur Icon-Verwaltung...

Für den Editor hab ich mir übrigens unter https://knx-user-forum.de/278241-post226.html schon ein paar Icons gewünscht...

[netzkind]

Ist es eigentlich geplant die XSD-Dokumentation als integrierte Hilfe mit zu benutzen (ggf. per Mapping-Tabellen auch noch in übersetzter Form?)

Steht in der DEVELOPMENT.txt als Idee. Übersetzungen sollten dann auch gleich im XSD liegen, dann annotations kann man im XSD "von Natur aus" mehrsprachig hinterlegen.

[netzkind]

Vielleicht könnte man die Auto - Vervollständigung auch auch die Icons erweitern:
Dazu müßte die ./lib/iconhandler.js geparst werden und die dynamischen Icons herausgefunden werden (z.Zt ab Zeile 130).

Ja, wird man können. Der Editor verwendet dafür etwas das ich spontan dataProvider genannt habe: eine einheitliche Schnittstelle, mit der man wahlweise vom Server, oder direkt per Javascript, "Auswahllisten" bereitstellen kann.

Ich kann die Icons ja mal mit in die Todo-Liste aufnehmen, dann kann ich da gleich erproben, inwiefern die dataProvider ihren Zweck erfüllen.

[netzkind]

Hi Jan,

Ich hab da noch was: wenn man ein Attribut aus einer Auswahlliste befüllt hat, kann man das nicht mehr ändern, die Auswahlliste zeigt bei nochmaligem Klicken nur das ausgewählte Element und löschen kann man es auch nicht mehr. Aufgefallen ist mir das bei diagram_info im rrd-Attribut.

dann ist das noch nicht intuitiv genug.
Sobald im Eingabefeld etwas steht, tauchen in der Auswahlliste nurnoch die Elemente auf, welche "die Eingabe" als Namensbestandteil haben. Wenn "die Eingabe" jetzt bspw. "Systa_Status_TV1S-Vorlauftemperatur-HK1-Soll" lautet, dann gibt es in der Auswahlliste nur eine Zeile die dazu passt - deshalb wird nur die angezeigt.
Du kannst aber im Eingabefeld selbst jederzeit direkt mit der Tastatur arbeiten.

Vielleicht sollte ich dem Eingabefeld zur Verdeutlichung noch ein löschen-x verpassen. Mal schauen.

Edit: Und bei den rrd-Subelementen erscheint keine Auswahlbox für die existierenden RRDs

Ist bekannt.

Edit2: Und die rrd dürfen keine .rrd Endung haben, die wird automatisch vom diagram-Plugin angehängt und sonst verdoppelt.

Ist bekannt, und bei mir schon gefixt. Kommt noch vor dem nächsten Milestone.

Grüße,
Julian

[netzkind]

Da muss nix geparst werden, einfach die Datei mit einbinden und nutzen - der Iconhandler ist im Grunde nur eine kleine Datenbank zur Icon-Verwaltung...

Ich hab mich jetzt doch dazu entschieden, stattdessen direkt im Dateisystem nachzuschauen, welche Icons es gibt.

Der Gedanke, eine Editor-fremde JS-Datei dynamisch nachzuladen, die dann im globalen Namensraum rumliegt und Methoden bereitstellt die ich nicht brauche missfällt mir. Ganz abgesehen von den timing-Kopfschmerzen die beim dynamischen nacheinbinden von JS-Dateien und der anschließenden Nutzung selbiger entsteht ...

Aber vielleicht findet sich dafür noch ein sauberer Ansatz.

Jedenfalls: im SVN ist mit revision 1287 einerseits ein DataProvider für Icons, und andererseits eine ganze Reihe an Bugfixes (#text-Knoten entfernt wo sie unsinnig sind, rrd-Element mit DataProvider, .rdd aus den Dateinamen entfernt, Eingabefelder der Auswahllisten korrigiert, Konfiguration-Speichervorgang beschleunigt).

[ZeitlerW]

Hallo Julian,

suupi, die Icon - Vorschau funktioniert! Vielen Dank!
.rrd funzt auch.
vG
Wolfgang

[Chris M.]

Ich hab mich jetzt doch dazu entschieden, stattdessen direkt im Dateisystem nachzuschauen, welche Icons es gibt.

Der Gedanke, eine Editor-fremde JS-Datei dynamisch nachzuladen, die dann im globalen Namensraum rumliegt und Methoden bereitstellt die ich nicht brauche missfällt mir. Ganz abgesehen von den timing-Kopfschmerzen die beim dynamischen nacheinbinden von JS-Dateien und der anschließenden Nutzung selbiger entsteht ...

Klar, Du machst den Editor und nimmst das, was dafür am besten geeignet ist.
Der Iconhandler sollte allerdings deutlich "sparsammer" mit dem globalen Namensraum umgehen - nämlich nur sich selbst belegen... Auch der Overhead der einzelnen Funktionen ist sehr überschaubar, da sehr schlank. (Man merkt vermutlich, dass das meine neueste JavaScript "Anwendung" ist...)

Was natürlich gegen den IconHandler sprechen kann: der User mag evtl. auch eigene Icons erst einbinden, die dem IconHandler erst bekannt gemacht werden müssen (was aber z.B. per PHP natürlich relativ einfach geht).

Andererseits löst der Iconhandler die ganze Mögliche Vererbungshierachie richtig auf. Hier kann so Doppelarbeit vermieden werden und insb. bei zukünftigen Erweiterung hoffentlich leichter kompatibel bleiben (wie z.B. das kürzlich hinzugekommene Color)

Aber s.o.: nimm was am besten passt und die wenigste Arbeit macht

[alexbeer]

Hallo,
der Editor wir immer besser. Klasse!
Habe in den Attributen von "page" noch festgestellt, dass bei "flavour" und auch bei "shownavbar" die Auswahl der möglichen Werte fehlt.

Ich denke, dass lediglich die XSD von

    <xsd:attribute name="showfooter" type="xsd:boolean" use="optional" />
    <xsd:attribute name="shownavbar" type="xsd:string" use="optional" />

nach

 
    <xsd:attribute name="shownavbar" type="xsd:boolean" use="optional" />

geändert werden müsste.

P.S.
Ich bin leider nicht in der Lage die Bugs selbst zu beheben.
@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

[makki]

Also vorab, ich bin Julian noch eine längliche AW schuldig, die ist aber so lang das ich sie kürzen muss, daher erstmal hier im Kontext:

Da fällt mir ein: Es gab zunächst eine Fehlermeldung, dass der Server die Datei nicht speichern konnte. Ein chmod 777 visu_config.xml*) hat das behoben und ich konnte speichern

Mit Verlaub, das sind DAU-Probleme die im Release per Paket gelöst werden, vorher richtig gemacht wurden oder root kann das ohne zu fragen lösen..
SVN ist SVN, chmod kann man da.. Nächster Punkt..

Vielleicht könnte man die Auto - Vervollständigung auch auch die Icons erweitern:

Halte ich für gut.. Einfach alles unter /icons /media mit einem PHP reinblasen, kostet 200ms..

Ja, wird man können. Der Editor verwendet dafür etwas das ich spontan dataProvider genannt habe: ...

Wenn das PHP zu langsam ist, könnte man solch statische Daten auch als JSON oder so ablegen..

Zum Preview (das kennt Julian schon) habe ich die Idee einfach blind bei jeder Änderung temporär zu speichern und in einen jQuery-Tab diese 1:1 als iFrame(?) anzuzeigen.
Muss man aber ausprobieren, die Idee ist theoretisch..

Makki

[swiss]

Da es hier um den Editor im allgemeinen geht...

Ich habe gerade wieder ein URL Problem. Dieses mal mit dem Image Widget.

Ich würde gerne folgende Grafik einbinden:

http://www.yr.no/place/Switzerland/Z.../meteogram.png

Die adresse ist 100% valide aber der Editor will die Adresse nicht als valide anerkennen. Könnte es sein, dass esmit der Behandlung von Umlauten oder Sonderzeichen zu tun hat? Da ist ein ~ drin...

...Dann müsste man da unbedingt einen Konverter einbauen, der die Umlaute selbstständig konvertiert. Man kann ja nicht von OTTO verlangen, dass er sich mit Maskierung auskennt.

-> Ja auch wenn es die Linuxer und Unixer nicht gerne lesen oder hören... Umlaute sind schon seit ein paar Jahren in der URL erlaubt. Und auch die CV sollte damit problemlos umgehen können.

[greentux]

ich denke das "ä" da drin ist noch schlimmer als das ~

[swiss]

Hi greentux.

Das bestätigt mein Verdacht. Danke

Da wären wir also wieder beim Thema. ÄÖÜ sind seit ein paar Jahren in URL's zulässig. Da sollte die CV bzw. der Editor dies auch können.

[Tru]

http://www.yr.no/place/Switzerland/Z.../meteogram.png

Die adresse ist 100% valide aber der Editor will die Adresse nicht als valide anerkennen. Könnte es sein, dass esmit der Behandlung von Umlauten oder Sonderzeichen zu tun hat? Da ist ein ~ drin...

Soweit hast du Recht, der URL ist 100% valide, aber es hat auch keinen Umlaut drinnen ... wenn man genau hinschaut heisst der Link (ich hoffe es bleibt hier in echt vorhanden):

http://www.yr.no/place/Switzerland/Z%C3%BCrich/St%C3%A4fa~2658518/meteogram.png

Wenn man die Linkadresse kopiert, kann man es prüfen.

-> Ja auch wenn es die Linuxer und Unixer nicht gerne lesen oder hören... Umlaute sind schon seit ein paar Jahren in der URL erlaubt. Und auch die CV sollte damit problemlos umgehen können.

Das stimmt hingegen gar nicht. Die entsprechenden RFCs sind klar und eindeutig: Umlaute und weitere Sonderzeichen sind in URLs nicht erlaubt genau so wenig wie im DNS Protokoll, sondern müssen kodiert werden, gemäss IDN, was unterdessen der Standard ist. In der Darstellung dürfen dann Umlaute gezeigt werden, wie in deinem Beispiel.

Gruss, Othmar

[swiss]

Hallo Othmar

Hmm... Stimmt. Anscheinend hat der Browser die URL selber so codiert, dass keine Umlaute mehr drin sind. Dann verstehe ich aber nicht wo der Editor Probleme hat. Könnte es doch das Sonderzeichen ~ sein?

EDIT: Habe es gerade mal getestet aber das ~ ist es nicht. Dann bleiben eigentlich nur noch die % die zur Maskierung benötigt werden...