XML/XSD - brauchbarer Editor

[makki]

Ich hätte mal eine Frage: kennt jemand einen *brauchbaren* XML-Online Editor, der auch gleich XSD verarbeitet (und als Basis nimmt/darauf basiert) ?

Ich hab da jetzt wirklich lang gesucht und ausser wirrem Zeugs nichts halbwegs brauchbares an Vorlage gefunden (vielleicht Suche ich auch nach dem falschen, muss ja nicht 100 perfekt passen..); kann ja eigentlich nicht sein, da muss es doch was geben..

-> Es geht primär darum, die mappings, stylings, navbar? etc. Anwendertauglich abzubilden, was ja im XSD schon steht, wies aussehen soll/darf, macht ja keinen Sinn das nochmal von Hand zu malen
XForms ist tot, oder?

Any hints/Beispiele willkommen. Präferiert jQuery aber wegen mir auch mit Dojo oder YUI oder... Hat mit der Visu und dem grafischen Editor ggfs. ja nur am Rande zu tun.

Makki

[greentux]

Zusammengefasst sowas hier
Generating an XML Editor based on XSD using EMF | goELITE.org Techblog
fürs Web?

[makki]

Genau, Browser-based, ohne Java und ohne das wirre Eclipse-gedrösel wo die Lösung das Problem ist und nicht umgekehrt
Ausserdem ist das keine "Anwendertaugliche" Option fürs Feld;

Gibts wohl einfach nicht, ich hab jetzt mal angefangen das mit jsTree zu pinseln, da sollte nach einem ersten Test 90% gehen was man braucht..

Makki

[Chris M.]

Kennen tue ich auch nichts - bei so etwas würde ich aber bei StackExchange fragen.

Einen vollwertigen XML Editor braucht's hier aber IMHO gar nicht. So ausdrucksstark ist die Config-Datei nicht. Der Weg per jsTree dürfte da durchaus zielführend sein.

[makki]

Ich bin mir mittlerweile sicher, das gibts weder in jQuery noch YUI noch Dojo..

Es führt halt die ganze XML-Bloatware ad-absurdum wenn man dann nichts davon hat aber ich gehe jetzt mal den Weg, das XSD quasi - ohne es zu verwenden - in code nachzumalen (was irgendwie ohne das XSD natürlich total dämlich ist und das ganze system ad-absurdum stellt..)

Aber man muss es immer positiv sehen: Lessons learned: XML sieht nicht nur total nutzlos aus, sondern ist es ohne Eclipsesoritis auch
Optional/Notfalls wird das XML in JSON gewandelt, da gibts wenigstens was mit stark volatilem/custom Schema - aber fertigem Code dazu und das funktioniert im gegensatz zu dem ganzen xslt-plempel

Makki

[Chris M.]

Aber man muss es immer positiv sehen: Lessons learned: XML sieht nicht nur total nutzlos aus, sondern ist es ohne Eclipsesoritis auch

<flamewar an>
Aus Deiner Sicht mag das so sein.
Aber XML hat einen riesigen Vorteil vor anderen Config-Sprachen wie JSON oder INI: ich kann definieren wie die aufgebaut sein muss (-> XSD oder früher DTD) und brauche mich nicht mehr mit Fehlerbehandlungen bei invalider Syntax rumschlagen. Denn dass lässt sich ja schon vorher automatisch checken.

Das bringt auch uns schon einen Vorteil:
Hast Du mal seit Revision 843 (und am besten auch 862) probiert eine invalide Config-Datei zu verwenden und einen Config Check zu machen?
Wenn ich das alles im JavaScript beim JSON-Parsen abfangen sollte wäre der Code mehr als doppelt so dick und um mindestens eine Größenordung mehr Fehleranfällig...
<flamewar aus>

Und wenn da jetzt jemand beim Flamewar mitmachen will: ich hab einen dicken Feuerlöscher um den in der Wurzel gleich wieder zu löschen

PS: Das die Zahl der brauchbaren XML-Editoren so enttäuschend ist finde ich auch erstaunlich.

[makki]

<flamewar an>
Aus Deiner Sicht mag das so sein.
Aber XML hat einen riesigen Vorteil vor anderen Config-Sprachen wie JSON oder INI: ich kann definieren wie die aufgebaut sein muss (-> XSD oder früher DTD) ...

Theoretisch, ja.. Praktisch ist es halt traurig wenn man es nicht verwenden kann weil es nicht (überall/brauchbar) umgesetzt ist und man sich dann solchen Krücken wie Editor->Prüf-PHP->Fehlermeldung bedienen muss

Ob sich das jetzt gegen XML, jQuery oder Browser richtet sei dem Leser überlassen (warum gibts da kein sinngemäss check_xml_data(XML,XSD), onerror = ?)

PS: Das die Zahl der brauchbaren XML-Editoren so enttäuschend ist finde ich auch erstaunlich.

Das ist der eigentliche Kritikpunkt..
Aber jetzt mal lieber wieder an den Code, jammern hilft nix

Makki

P.S.: Es gibt JSON schema generator , kenn ich aber auch erst seit 3 Tagen..

[Chris M.]

(warum gibts da kein sinngemäss check_xml_data(XML,XSD), onerror = ?)

Sehe ich auch so, hab daher mal eine Bounty angehängt: Validate an xml against xsd with JS/jQuery - Stack Overflow

[makki]

Und eine AW ist auch schon da, genauso wie ich es jetzt (notgedrungen) vorhatte: zum server senden, PHP, ..

-> Ein erstes sneak-preview ist im SVN commited, (edit_xml/) wie ich mir das so in etwa vorstelle.
- Das ist wirklich noch sehr roh und momentan völlig unbenutzbar!
-> RFC (Kommentare erwünscht)
- Das jQuery UI ist da im moment eher overload, hat aber einen gedanklichen Hintergrund

Das soll auch, nochmal - kein Ersatz für den WYSIWYG-Editor sein, sondern eine Ergänzug für dort schwer oder nur aufwändig umsetzbare Funktionen.
(wie mappings, stylings, komplette pages schieben etc.)
Und uns ersparen jeden Tag jemandem zu erklären wie er WinSCP und Notepad++ aufmacht (Tab2-unfertig)

Makki

[JuMi2006]

So einen globalen Online-Editor könnte das Webmin aber auch vertragen.
Mal eben ein Script, Plugin oder ne linknx Logik ändern ohne gleich scp und ssh anzuwerfen. Vor allem plattformunabhängig.

Nur mal so ein Feature-Request am Rande.

[mumpf]

Also ich hab mir nen Samba-Share aufgemacht (ja, ich bin bekennender Windows-User) und mir da alle Verzeichnisse reingelinkt, die mich interessieren. Den Share hab ich immer in Windows gemountet und greife darauf mit meiner Entwicklungsumgebung zu. Somit habe ich vernünftige Projekte für linknx, comet, fhem (mein Privates Spielzeug neben KNX) und die WG-Plugins. So hab ich auch keine Probleme, einen vernünftigen XML-Editor mit XSD-Unterstützung zu nutzen - um mal wieder zum Thema zu kommen...

Gruß, Waldemar

[makki]

So einen globalen Online-Editor könnte das Webmin aber auch vertragen.

Ertappt, jetzt weiste auch warum da mit jQ UI soviel "bloat" drin ist (und warum ein paar der Backend-PHPs fehlen, weil bis auf //TODO: leer) , ansich will ich von dem Webmin ja weg..

Makki

[Chris M.]

XML/XSD vs. JSON/JSON Schema

Habe nun auch etwas intensiver mal JSON Schema angeschaut. Auch wenn ich noch nicht ganz durchgestiegen bin, wie das dort mit den Regex läuft, schätze ich, dass damit in unserem Fall bei der Ausdrucksstärke JSON gleichwertig zu XML wird.
Dazu kommt, dass eine JSON sich deutlich schneller parsen lassen sollte als eine XML (Quellen sprechen von meheren Größenordnungen...)

=> Wenn wir die XSD nach JSON-Schema transferieren und dagegen Checken würden, kann ich mir vorstellen das Config-Datei-Format zu ändern.

Welche Pro/Contra Meinungen gibt es dazu?

[mumpf]

Hi Chris,

da Du derjenige bist, der hier (zumindest gefühlt) der Hauptakteur ist, steht Dir natürlich auch eine Entscheidung zu...

Da wir hier aber gerade in Thread über brauchbare XML/XSD-Editoren sind: Da gibt es immerhin einige (Eclipse, Visual Studio, oXygen), die gleich beim editieren validieren, Wertehilfen (code completion) anbieten, automatisch tags ergänzen (z.B. schließendes Tag), automatisch formatieren und color coding anbieten.

Für json/json schema kenne ich gar nichts in der Richtung. Es ist ein Krampf, json zu editieren (alleine schon wegen der geschweiften Klammern - soll kein Scherz sein, die <> in XML lassen sich wesentlich schneller tippen weil bequemer zu erreichen), danach erst durch einen Parser zu jagen, der es gegen das Schema verifiziert, um es dann auszuführen. Derzeit ist jede XML-Datei, die ich abspeichere, immer korrekt, weil ich schon VORHER sehe, ob da ein Fehler drin ist. Da wäre json meiner Meinung nach ein riesiger Rückschritt.

Und der eingebaute Editor wird ja auf absehbare Zeit das nicht auffangen können.

Schnelleres Parsen ist ein Punkt für json, allerdings hatte ich bisher hier noch keine Probleme - bis die Werte vom Bus da sind, ist das XML sicherlich mehrmals geparsed. Wäre für mich kein Grund, vom XML wegzugehen.

Also - alles in allem - ein CONTRA von meiner Seite.

Gruß, Waldemar

P.S.: Ich habe nicht vergessen, dass ich nochmal das XSD überarbeiten wolle - hab ich noch nicht geschafft - werde jetzt aber diese Entscheidung natürlich erstmal abwarten...

[hannes loehr]

Hi Chris,

ich habe mich jetzt noch nicht mit JSON-Schema beschäftigt, aber auf Anhieb sehe ich ein händisches erstellen/editieren eines JSON-Strings als nachteilig gegenüber XML. Die Unterstrukturen lassen sich meiner Ansicht im nackten Text besser erkennen als in einem Wust von geschweiften Klammern.

Ich benutze JSON für Ajaxaufrufe zwischen Jquery-Ajax und Pythonlogik, verwende aber immer eine Library wie jquery-json auf Google Code bzw. ein Gegenstück auf Pythonseite um Datenstrukturen zu (de-)serialisieren.

Wenn das alles automatisch über den Editor läuft, wäre es unerheblich. Eine umfangreiche visu_config sehe ich (noch) nicht in Json-Form.

Gruß
Hannes