XML-Strukturen und Darstellung
johny7
XML-Strukturen und Darstellung
johny7
Moin allerseits,
für einige Webprojekte überlege ich mir, XML an zu setzen. Das ist teilweise einfacher und schneller zu notieren, als der Umweg über HTML.
Für die Darstellung gibt es ja mit XSL und XSLT mächtige Werkzeuge. Da ich nun auf dem Stand der letzten SelfHTML-Doku bin, brauche ich eure Empfehlung:
Was sollte bevorzugt werden, eine server-seitige Auswertung oder eine clientseitige? Für das erste spricht auf jeden Fall die größere Kompatibilität. Aber wie ist das praktisch um zu setzen? Was läuft schneller ab? Ist es besser mit einem extra Modul für XSLT zu machen, oder kann man prinzipiell einfach XML z.B. per PHP nach HTML transferieren? Da hätte man ja wirkliche Programmiermöglichkeit. Und es wäre so, wie es gedacht ist: Daten werden mit XML nur strukturiert verfasst, die Strukturen in DTDs beschrieben, aber die Auswertung und Darstellung übernimmt eine Software.
Was schlägt ihr vor? Oder in Zukunft sich einfach weiter mit HTML herumschlagen? ;_(
Grüße, JN
--
ie:{ fl:( br:^ va:| ls:[ fo:| rl:? n4:? ss:| de:] js:| ch:? sh:( mo:| zu:)
http://www.johny7.de
ie:{ fl:( br:^ va:| ls:[ fo:| rl:? n4:? ss:| de:] js:| ch:? sh:( mo:| zu:)
http://www.johny7.de
-
moin,
Was schlägt ihr vor? Oder in Zukunft sich einfach weiter mit HTML herumschlagen? ;_(
Ich empfehle gar nichts. Meine Seiten werden als HTML ausgeliefert. XML ist mir sowohl aus der Sicht der Editierbarkeit(1) als auch aus der Sicht der Parserei(2) auf dem Server eine grausige Vorstellung. Daher habe ich zum Speichern meine URL-Objekte und OMS (Object Management System) in den letzten Wochen ein völlig eigenes Verfahren entwickelt, was
(1) die Speicherung meine Objecte in einer einfach editierbaren und durchschaubaren Textdatei im Format einer INI Datei ermöglicht,
(2) diese Objekte für den Webserver in eine Binärdatei serialisiert, die äußerst performant maschinell zu lesen ist.
Gerade auch das Letztere war mir wichtig, es ist so, dass das Parsen großer Datenmengen aus einer textlich strukturierten Datei (XML) zwar möglich und portable ist, aber damit auch die Performance extrem darunter leidet; für mich undenkbar, dies bei jedem Seitenaufruf tun zu müssen. Eine Binärdatei hingegen ist Low Level strukturiert (auf byte Ebene), wenn die in den Hauptspeicher gelesen wird, erzeugt das lediglich einen kleinen Burst ohne Overkill.
Eine Empfehlung habe ich dennoch: Es lohnt sich, darüber nachzudenken ;-)
Schönen Tach,
Hotti-
Weils so schön passt:
Ein Beiepiel einer Ajax-Response
in meinem Framework. Diese Response ist weder XML noch JSON ;-)
Serverseitig macht das eine simple Funktion
$PerlObject->serializeObject(); # $PerlObject ist eine Hashreferenz
Seitens DOM wird das mittels der JS Funktionen split() und decodeURIComponent() ratzfatz in ein Objekt verwandelt. Der kleinste gemeinsame Nenner zwischen JS und Perl heißt bei mir 'application/x-www-form-urlencoded', leider kann JS nicht mit byte(low level)-Strukturen umgehen, dann sähe die Response nochn bischen besser aus ;-)
Endlich Feierabend,
Hotti -
Tach.
Was hat das ...
Ich empfehle gar nichts. Meine Seiten werden als HTML ausgeliefert. XML ist mir sowohl aus der Sicht der Editierbarkeit(1) als auch aus der Sicht der Parserei(2) auf dem Server eine grausige Vorstellung. Daher habe ich zum Speichern meine URL-Objekte und OMS (Object Management System) in den letzten Wochen ein völlig eigenes Verfahren entwickelt [...]
... und das ...
... mit der Frage des OP zu tun? Muß die Hälfte Deiner Beiträge in diesem Forum immer aus Interna Deiner Seite, Deines OMS oder Links auf irgendwelche selbstverfaßten, unausgegorenen Artikel bestehen? Ich komme mir bei Dir allmählich vor wie in einer Werbesendung.
--
Wenn es schwingt, ist es ein Filter – Oszillatoren würden so etwas nie tun.
-
-
Tach.
Was sollte bevorzugt werden, eine server-seitige Auswertung oder eine clientseitige? Für das erste spricht auf jeden Fall die größere Kompatibilität. Aber wie ist das praktisch um zu setzen? Was läuft schneller ab? Ist es besser mit einem extra Modul für XSLT zu machen, oder kann man prinzipiell einfach XML z.B. per PHP nach HTML transferieren?
Schön wäre es natürlich, wenn man sich hundertprozentig auf einen XSLT-fähigen Client verlassen könnte. Ansonsten stehen einige User ganz schön im Regen. Ich bin da zurückhaltend und mache das ausschließlich serverseitig. In PHP steht dazu beispielsweise die XSLTProcessor-Klasse zur Verfügung, die auf libxslt basiert und somit leider auf XSLT 1.0 beschränkt ist. Vielleicht reicht Dir das aber auch.
Für einige Anwendungen lasse ich mir statische HTML-Seiten per XSLT in Saxon (kann auch XSLT 2.0, hurra!) aus den XML-Sources generieren. Dabei passieren dann unter anderem auch gleich Sachen wie Querverweise, Numerierungen von Formeln und Bildern. Das mit den statischen Seiten ist aber vermutlich nicht ganz Dein Anwendungsfall, oder?
Was Geschwindigkeitsunterschiede zwischen der Client- und Server-Variante angeht: keine Ahnung. Durch schlechte Performance ist die obige PHP-Lösung mir bisher zumindest nicht aufgefallen. Allerdings habe ich sie bisher auch nur in kleinen bis mittelgroßen Projekten eingesetzt.
[Ich kann mich dunkel daran erinnern, einst ein umfangreicheres CMS, welches konsequenz diesen XML-XSLT-Ansatz umsetzte, in den Fingern gehabt zu haben. Wenn ich mich an den Namen erinnere, reiche ich ihn nach. :)]
Was schlägt ihr vor? Oder in Zukunft sich einfach weiter mit HTML herumschlagen? ;_(
Ich finde die Variante mit XML und XSLT an sich recht praktisch. Alle notwendigen Daten strukturiert im XML zusammengesammelt und, je nach Stylesheet, mit XSLT in die entsprechende Ausgabeform gebracht. Ich hab's vor allem aus Neugier ausprobiert. Je nach Projektgröße ist das jedoch ziemlich umständlich gegenüber "direktem" HTML. Ich würde nicht generell mit der XSLT-Kanone auf jeden Spatzen schießen ...
--
Wenn es schwingt, ist es ein Filter – Oszillatoren würden so etwas nie tun. -
Hallo,
Was sollte bevorzugt werden, eine server-seitige Auswertung oder eine clientseitige?
clientseitige ist derzeit meiner Meinung nach im Allgemeinen nicht brauchbar.
[...]
Da hätte man ja wirkliche Programmiermöglichkeit. Und es wäre so, wie es gedacht ist: Daten werden mit XML nur strukturiert verfasst, die Strukturen in DTDs beschrieben, aber die Auswertung und Darstellung übernimmt eine Software.
Ich kenne ein Projekt, bei dem dies gescheitert ist und bei dem Bearbeiter sagen, ...
für einige Webprojekte überlege ich mir, XML an zu setzen. Das ist teilweise einfacher und schneller zu notieren, als der Umweg über HTML.
... dass das für sie nicht zutraf.
Ich persönlich schreibe XML nicht von Hand, das ist *für mich* viel zu fehleranfällig. Es ist ein Format, das von vielen Programmen gut verarbeitet werden kann, für das es ausgezeichnete Bibliotheken für viele Programmiersprachen gibt und ein Format, das für Menschen (gerade noch) lesbar sein kann.
Was schlägt ihr vor? Oder in Zukunft sich einfach weiter mit HTML herumschlagen? ;_(
Ja klar. Was nutzt Dir das schönste XML, wenn anschließend unbrauchbares HTML herauskommt.
Freundliche Grüße
Vinzenz