nicht angemeldet
XML+XSLT: dynamische Änderung des XML möglich?
Hallo,
ich frage mich ob das folgende machbar ist:
Vom Webserver wird eine XML-Datei geliefert, die dann mit XSLT im Browser nach HTML gewandelt wird.
Ist es möglich das Ausgangs-XML (und nicht etwa das generierte HTML) dynamisch mit DOM zu ändern und eine entsprechend aktualisierte Darstellung im Browser zu erhalten?
Zu Erklärung:
Mir schwebt vor, dass das Ausgangs XML etwa so aussieht:
<section> Einleitung ...
<section> Abschnitt 1 ... </section>
<section> Abschnitt 2
<section> Abschnitt 2.1 </section>
</section>
</section>
Also ein relativ einfaches XML-Format.
Daraus soll per XSLT ein HTML mit H1, H2 usw gemacht werden. Zusätzlich sollen Buttons dazukommen um z.B. ein Abschnitt neu einzufügen, zu verschieben etc.
Das HTML wird also relativ komplex.
Das HTML kann ich (wahrscheinlich) mit DOM manipulieren (notwendig z.B. beim Verschieben eines Abschnitts). Problem: der Javascript-Code ist relativ komplex und muss bei Änderungen des XSLT entsprechend angepasst werden.
Wesentlich eleganter wäre es, das Original-XML per DOM zu manipuliert und den Browser dazu zu bringen kann daraus erneut HTML zu generieren.
Geht das überhaupt und ist es sinnvoll? (Laufzeit? Speicherbedarf?)
Als Alternative kann man natürlich eine aktualisierte Seite vom Browser laden lassen, aber das möchte ich nach Möglichkeit vermeiden.
Grüße
Ulrich
-
Hallo,
ich frage mich ob das folgende machbar ist:
Vom Webserver wird eine XML-Datei geliefert, die dann mit XSLT im Browser nach HTML gewandelt wird.
Ist es möglich das Ausgangs-XML (und nicht etwa das generierte HTML) dynamisch mit DOM zu ändern und eine entsprechend aktualisierte Darstellung im Browser zu erhalten?Nein.
Begründung: weil du es im Browser machen willst. Entweder versuchst du dein XML mit Hilfe von JavaScript (im Browser hast du keine andere Mögilchkeit mit DOM zu arbeiten) zu manipulieren, oder du machst eine XML/XSL-TRansformation: in dem Fall hast du schilcht HTML wobei im Mozilla einie Beschränkungen hast (da kannst du dein HTML nachher auch nicht mit JavaScript bearbeiten, da Mozilla das Ergebnis der Transformation schlicht ausgibt (serialisiert), wogegen der IE das Ergebnis-HTML nochmal als HTML parst.Zu Erklärung:
Mir schwebt vor, dass das Ausgangs XML etwa so aussieht:<section> Einleitung ...
<section> Abschnitt 1 ... </section>
<section> Abschnitt 2
<section> Abschnitt 2.1 </section>
</section>
</section>Also ein relativ einfaches XML-Format.
Einfach, aber schlecht.
Das HTML kann ich (wahrscheinlich) mit DOM manipulieren (notwendig z.B. beim Verschieben eines Abschnitts).
Im IE ja, im Mozilla nicht.
Wesentlich eleganter wäre es, das Original-XML per DOM zu manipuliert und den Browser dazu zu bringen kann daraus erneut HTML zu generieren.
Wenn du dabei nicht verrückt werden möchtest, mache das serverseitig.
Geht das überhaupt und ist es sinnvoll?
Ob es geht: vielleicht, aber nur vielleicht. Sinnvoll ist das nicht, wenn du es im Browser machen willst.
»»(Laufzeit? Speicherbedarf?)
Das hängt von der Größe der XML-Datei ab.
Als Alternative kann man natürlich eine aktualisierte Seite vom Browser laden lassen, aber das möchte ich nach Möglichkeit vermeiden.
Das wäre aber bei deiner Anforderungen die weitaus einfachere und schnellere Lösung.
Grüße
Thomas-
Hallo Thomas,
Im IE ja, im Mozilla nicht.
Das stimmt nicht und es hätte mich aus sehr gewundert, wenn es stimmen würde.
Der Mozilla parsed das erzeugte HTML-Dokument sicher nicht, das wäre ja auch reichlich ungeschickt, da der XSLT-Prozessor ja ein schönes DOM-Bäumchen erzeugt. Auf dieses hat man dann per Javascript natürlich auch Zugriff.Grüße
Daniel
-
Hallo,
Im IE ja, im Mozilla nicht.
Das stimmt nicht und es hätte mich aus sehr gewundert, wenn es stimmen würde.Was stimmt an dem Satz bitte nicht?
Der Mozilla parsed das erzeugte HTML-Dokument sicher nicht, das wäre ja auch reichlich ungeschickt,
So? Warum wäre es ungeschickt das Ergebnis-HTML richtig zu serialisieren?
da der XSLT-Prozessor ja ein schönes DOM-Bäumchen erzeugt. Auf dieses hat man dann per Javascript natürlich auch Zugriff.
Das ist ein teilweise Irrtum. Mozilla parst das HTML nicht mehr, was aber mitunter nötig wäre.
Möchtest du ein Beispiel? http://www.iowatelecom.net/~elwing/web_design/debug/events.xml vergleiche mit dem IE.
Zu folge (Grund ist der verwendeten Transformiix Version im Mozilla) gibt auch das Problem mit <xsl:text disable-output-escaping="yes">. Du kannst auch den Bug (welcher mit VERIFIED WONTFIX abgetan wurde) duchlesen: https://bugzilla.mozilla.org/show_bug.cgi?id=98168
Grüße
Thomas-
Hallo Thomas,
Was stimmt an dem Satz bitte nicht?
Das sagte ich doch, auch im Mozilla hat man Zugriff mit JS auf den erzeugten HTML-Code.
Dass ein (mehrere?) XSLT-Features nicht unterstüzt werden, ist ja ein anderes Thema.So? Warum wäre es ungeschickt das Ergebnis-HTML richtig zu serialisieren?
Zu serialisieren und dann wieder zu parsen ist umständlich und kostet Zeit. Das wollten die Mozillaentwickler wohl nicht in Kauf nehmen.
Evt. könnte man das natürlich geschickter implementieren, indem man nur einen Teil parsed, so wie man es auch bei innerHTML tut. Aber ich kenne die XSLT-Spezifikation nicht so genau, dass ich wüsste, ob es da nicht noch irgend welche Spitzfindigkeiten gibt.Grüße
Daniel
-
Hallo Daniel,
Was stimmt an dem Satz bitte nicht?
Das sagte ich doch, auch im Mozilla hat man Zugriff mit JS auf den erzeugten HTML-Code.Und ich versuche klarzumachen, dass das nicht immer stimmt.
(du sagt gar nichts zu dem Bsp. dass ich dazu angab(?))
(Es gibt auch genau dazu Bug-Meldungen im Bugzilla z.B. https://bugzilla.mozilla.org/show_bug.cgi?id=221640)Dass ein (mehrere?) XSLT-Features nicht unterstüzt werden, ist ja ein anderes Thema.
Ja, aber beide haben dieselbe Ursache.
So? Warum wäre es ungeschickt das Ergebnis-HTML richtig zu serialisieren?
Zu serialisieren und dann wieder zu parsen ist umständlich und kostet Zeit. Das wollten die Mozillaentwickler wohl nicht in Kauf nehmen.Kann ich nicht akzeptieren. Vor 2 oder 3 Jahren war das ein Argument. Heute ist das eine Ausrede. Der standalone version von Transformiix (der XSLT-Prozessor in Mozilla) macht alles ordentlich.
Evt. könnte man das natürlich geschickter implementieren,
Ja, wenn man es ordentlich machte. ;-)
Grüße
Thomas-
Hallo Thomas,
Und ich versuche klarzumachen, dass das nicht immer stimmt.
Wenn Du das so formuliert hättest, hätte ich Dir auch nicht widersrpochen. Es klang nur so, als würde es überhaupt nicht gehen. Tatsächlich geht es aber fast immer (nur Scripts beim Aufbauen der Seite und Ausgabe von Markup als Text funktionieren nur teilweise/ gar nicht. Für die meisten Anwendungen dürfte das unproblematisch sein, was natürlich kein Grund ist, die Fehler zu beheben.
(du sagt gar nichts zu dem Bsp. dass ich dazu angab(?))
Ich habe hier keinen IE und konnte daher nicht vergleichen.
Kann ich nicht akzeptieren. Vor 2 oder 3 Jahren war das ein Argument. Heute ist das eine Ausrede. Der standalone version von Transformiix (der XSLT-Prozessor in Mozilla) macht alles ordentlich.
Nunja viele Leute benutzen auch heute noch Rechner von vor 2/3 Jahren. Vondaher ist es heute u.U. immer noch ein Argument, wenn es damals eines wahr.
Aber wenn der zuständige Entwickler das nicht machen will, kann man sowieso nur darauf verzichten oder er selber machen.Grüße
Daniel
-
-
-
-
-
Zu Erklärung:
Mir schwebt vor, dass das Ausgangs XML etwa so aussieht:<section> Einleitung ...
<section> Abschnitt 1 ... </section>
<section> Abschnitt 2
<section> Abschnitt 2.1 </section>
</section>
</section>Also ein relativ einfaches XML-Format.
Einfach, aber schlecht.
Wieso schlecht? Als Verbesserung fällt mir z.B. folgendes ein:
<section>
<content> Einleitung </content>
<section> ...aber ansonsten? Das section rekursiv in section enthalten ist, will ich so haben (anstatt von subsection, subsubsection ...), damit man die Struktur durch direktes Umhängen der Nodes verändern kann. Und nebenbei bemerkt ist so etwas auch nicht unüblich siehe z.B. die Strukturbeschreibung eines E-Learningkurses mit SCORM:
<item identifier="MODULE1">
<title>Module 1 -- Basics</title>
<item identifier="LESSON1" identifierref="RESOURCE_LESSON1">
<title>Lesson 1 -- Interface</title>
</item>Wenn du dabei nicht verrückt werden möchtest, mache das serverseitig.
Das will ich nicht. Als Hobbyprojekt und Fingerübung soll dies ein rudimentärer Editor (für ein spezielles XML-Format) werden. (für Notizen, Todo-Listen , Materialsammlungen als Basis längerer Texte ...). Das Umsortieren der Reihenfolge dürfte relativ häufig vorkommen und sollte nach Möglichkeit ohne Serverunterstützung ablaufen. (und eben nicht: Abschitt eine Stufe nach vorne, 1/2 Sekunde auf den Server warten, Abschitt eine Stufe nach vorne, 1/2 Sekunde warten ...)
Ich habe in der Zwischenzeit selber weiter herumgesucht um das folgende gefunden:
http://devedge.netscape.com/viewsource/2003/xslt-js/
Damit könnte es gehen.Ulrich
-
Hallo,
Also ein relativ einfaches XML-Format.
Einfach, aber schlecht.
Wieso schlecht? Als Verbesserung fällt mir z.B. folgendes ein:
<section>
<content> Einleitung </content>
<section> ...Besser, in solchen Fällen ist es wirklich besser, wenn du ein Element wie <content> oder <titel> etc. verwendest und nicht auf das "mixed content"-Modell setzt.
aber ansonsten? Das section rekursiv in section enthalten ist, will ich so haben (anstatt von subsection, subsubsection ...),
Weil in den meisten Fällen genau diese Rekursion später die Ursache für so manches Problem ist. Mir ist das auch so recht. ;-)
Und nebenbei bemerkt ist so etwas auch nicht unüblich
Nur weil es einige so machen, heisst es keineswegs, dass das richtig wäre.
siehe z.B. die Strukturbeschreibung eines E-Learningkurses mit SCORM:
Das sind lediglich 2 Ebenen. Deine Struktur lässt aber auf 3,4,5 etc Ebene schließen.
Wenn du dabei nicht verrückt werden möchtest, mache das serverseitig.
Das will ich nicht.
OK. ;-)
Ich habe in der Zwischenzeit selber weiter herumgesucht um das folgende gefunden:
http://devedge.netscape.com/viewsource/2003/xslt-js/
Damit könnte es gehen.Wenn du im Archiv suchst, findest du von mir komplette Kodebeispiele wie das gemacht werden kann, auch mit Parameterübergabe aus JavaSript an XSLT etc. (mitunter für crossbrwoser Verwendung)
Grüße
ThomasPS: Und wenn du in ein oder zwei wochen hier wieder reinschaust, wird es genau zu diesem Thema ein Feature-Artikel geben. ;-)
-
Besser, in solchen Fällen ist es wirklich besser, wenn du ein Element wie <content> oder <titel> etc. verwendest und nicht auf das "mixed content"-Modell setzt.
Ok. Wahrscheinlich hätte ich es eh so gemacht (neben anderen Dingen wie eindeutige IDs der Knoten). Das XML-Beispiel ist stark vereinfacht.
siehe z.B. die Strukturbeschreibung eines E-Learningkurses mit SCORM:
Das sind lediglich 2 Ebenen. Deine Struktur lässt aber auf 3,4,5 etc Ebene schließen.
Es gibt auch Beispiele mit mehr Ebenen. Und gerade bei Kursmaterial ist soetwas auch sinnvoll. Z.B. du hast mehr Material als du brauchst. Dann musst du auswählen: die oberste Ebene (Einleitung, Hauptteil, Anhang) fällt weg, es bleibt nur der Hauptteil übrig -> aus einem subsection wird ein section, aus einem subsubsection ein subsection usw.
D.h. jeder Knoten ändert seinen Typ (Namen ?), was relativ aufwendig ist (anstelle eines einfachen Umhängens im Baum muss jeder Knoten angefasst werden).Aber letztendlich ist das für mich Weiterbildung, gut möglich, dass ich auf dem Holzweg bin.
PS: Und wenn du in ein oder zwei wochen hier wieder reinschaust, wird es genau zu diesem Thema ein Feature-Artikel geben. ;-)
Den werde ich mir auf jeden Fall ansehen.
Ulrich
-
-
-