XML/XSLT Webserver

[hummer]

Hallo,

ich möchte gerne ein XML-Seite basteln und diese über PHP und MySQL
erstellen und dann per XSLT verarbeiten. Meine Seite soll aber erst
vom Server geparst werden und dann lediglich das erzeugte HTML-Skript
an den jeweiligen Client bzw. Browser geschickt werden. So nun hätte
ich gerne gewusst, wo ich einen solchen Webserver finde der XML
unterstützt, so dass bei anfragen auf dem Server geparst wird? Hab
schon bei ein paar Anbietern geguckt nur leider nichts passendes
gefunden.

Gruß Hummer

[wahsaga]

hi,

So nun hätte ich gerne gewusst, wo ich einen solchen Webserver finde der XML unterstützt, so dass bei anfragen auf dem Server geparst wird?

Wie dir wikipedia: XSLT schon hätte verraten können, brauchst du dazu einen XSLT-Prozessor.

In PHP gibt es dafür z.b. die Erweiterungen für XSLT Funktionen oder XSL Funktionen - du müsstest dir also nur einen Hoster suchen, der diese auch in seinem PHP-Paket mit anbietet.

gruß,
wahsaga

[XaraX]

Moin Hummer,

ich möchte gerne ein XML-Seite basteln und diese über PHP und MySQL
erstellen und dann per XSLT verarbeiten. Meine Seite soll aber erst
vom Server geparst werden und dann lediglich das erzeugte HTML-Skript
an den jeweiligen Client bzw. Browser geschickt werden.

so, wie Du es hier geschildert hast, ist das Unterfangen als nicht sinnvoll zu bezeichenen. Es gibt Möglichkeiten die aus eine Datenbank gewonnenen Daten mittels PHP in XML zu fassen (erster Parsevorgang) und diese dann mit einem Apache-Modul wie http://sourceforge.net/projects/mod-xslt/ zu HTML zu konvertieren (zweiter Parsevorgang). Nur warum soll nicht sofort von PHP HTML ausgegeben werden?

Begründet durch mögliche Clients, die XML benötigen, sehe ich hier dennoch nicht, warum solch ein Aufwand betrieben werden soll, da PHP hier per Fallunterscheidung einmal HTML (direkt) ausgeben kann und einem XML.

Ich vermute, das aus der Datenbank gleich XML-formatierte Daten ausgelesen werden. Sollte dem so sein, brauchst Du nur einen Provider, der PHP unterstützt. Den Parser kannst Du selbst schreiben, oder bei http://pear.php.net/package/XML_Parser etwas schmulen ;)
 Wenn sich XSLT für Dich als unabdingbar erweist, dann interessiert Dich vielleicht auch noch http://pear.php.net/package/XML_XSLT_Wrapper.

Gruß aus Berlin!
eddi

[Thomas J.S.]

Hallo,

ich möchte gerne ein XML-Seite basteln und diese über PHP und MySQL
erstellen und dann per XSLT verarbeiten. Meine Seite soll aber erst
vom Server geparst werden und dann lediglich das erzeugte HTML-Skript
an den jeweiligen Client bzw. Browser geschickt werden.

so, wie Du es hier geschildert hast, ist das Unterfangen als nicht sinnvoll zu bezeichenen.

Würdest du deine aussage bitte begründen?
Ich kann nichts sinnloses an dem Vorhaben feststellten.
Zudem stehen im PHP seit Version 5 - statt Umwege über zu installierenden Pakages (oder Moduls, die man ohne Zugrifft auf das OS des Server nicht installieren kann)  - mit simpleXML oder libxml und libxslt verschiedene eingebaute Funktionen zur Verfügung.

Grüße
Thomas

[XaraX]

Hallo Thomas,

ich möchte gerne ein XML-Seite basteln und diese über PHP und MySQL
erstellen und dann per XSLT verarbeiten. Meine Seite soll aber erst
vom Server geparst werden und dann lediglich das erzeugte HTML-Skript
an den jeweiligen Client bzw. Browser geschickt werden.

so, wie Du es hier geschildert hast, ist das Unterfangen als nicht sinnvoll zu bezeichenen.
[PHP] ... (erster Parsevorgang)... [XSLT-Pozessor] ...(zweiter Parsevorgang)...

Würdest du deine aussage bitte begründen?

ja. (Nur - ich hatte gehofft es bereits getan zu haben.) Wenn aus einfachen Daten, die aus einer Datenbank gewonnen werden, mittels PHP ein XML-Dokument erzeugt wird (erster Parsevorgang), was dann mit einem Apache-Fliter in HTML umgewandelt wird (zweiter Parsevorgang), so hat dieses Verfahren hinsichtlich der einfachen Generierung von HTML mittels PHP Nachteile. Die Maschine wird mit unnötiger Rechenarbeit belastet.

Um ein ähnliches Beispiel zu geben: Es ist genausowenig sinnvoll mittels PHP permanent dynamischen Templates für SSI zu generieren. Man sollte _dann_ stattdessen nur auf die Möglichkeiten, die PHP von Hause aus bietet, zurückgreifen.

Ich kann nichts sinnloses an dem Vorhaben feststellten.

XML-Dokumente _zu_nutzen_ und diese via XSLT zu transformieren - daran ist auch für meine Begriffe nichts sinnloses zu entdecken (wie die Apache-Docu bspw. zeigt).
XML-Dokumente _zu_generieen_ und diese via XSLT zu transformieren stellt aber einen Overhead dar.

Zudem stehen im PHP seit Version 5 - statt Umwege über zu installierenden Pakages (oder Moduls, die man ohne Zugrifft auf das OS des Server nicht installieren kann)  - mit simpleXML oder libxml und libxslt verschiedene eingebaute Funktionen zur Verfügung.

Vorsicht!
Diese sind standardmäßig zwar aktiviert, die entsprechenden Bibliotheken müssen dennoch vorhanden sein, was ein entsprechenden Zugriff auf das OS auf den (hoffentlich) beflissenen Admin verschiebt. Es sind auch in Version 5 nur Erweiterungen PHPs und müssen nicht zur Verfügung stehen. Aber ich denke, wir sind uns darüber einig, das bereits implementierten Funktionen aus Gründen der Performanz immer den Vorrang vor in PHP programmierten Funktionen zu geben ist.

Auch wenn dies etwas viel verlangt sein mag, aber selbst Datenbankabfragen - ja jede Erweiterung PHPs, läßt sich weitestgehen durch die Mittel PHPs (als Programmiersprache) nachbilden und stellen im eigentlichen Sinne nur nette Hilfsmittel dar.

Gruß aus Berlin!
eddi

[Thomas J.S.]

Hallo eddi,

so, wie Du es hier geschildert hast, ist das Unterfangen als nicht sinnvoll zu bezeichenen.
[PHP] ... (erster Parsevorgang)... [XSLT-Pozessor] ...(zweiter Parsevorgang)...

Würdest du deine aussage bitte begründen?

ja. (Nur - ich hatte gehofft es bereits getan zu haben.) Wenn aus einfachen Daten, die aus einer Datenbank gewonnen werden, mittels PHP ein XML-Dokument erzeugt wird (erster Parsevorgang), was dann mit einem Apache-Fliter in HTML umgewandelt wird (zweiter Parsevorgang), so hat dieses Verfahren hinsichtlich der einfachen Generierung von HTML mittels PHP Nachteile. Die Maschine wird mit unnötiger Rechenarbeit belastet.

Gut, wenn man nur von einem "Daten aus der DB --> HTML" ausgeht, _mag_ der Weg über XML/XSLT (also "Daten aus der DB ---> XML/XSLT --> HTML") als ein Umweg erschienen. Es kommt aber auf die Daten und auf die Ausgabe an.
In so einem Fall ist oft ein ziemlicher Arbeit das Ausgabescript zu schreiben (mit all dem HTML etc. drinn) und bei Änderungen muss dieses immer wieder angefasst werden. Da sind zwei Scripte die jeweils nur etwas bestimmtest tun, einfacher zu schreiben und auch zu verwalten. So ein Last auf der Serverseite verursacht das nicht (wir haben mal in einem Projekt zu dieser Frage sogar Benchmark-Tests gemacht (auch hinsichtlich Wartbarkeitsaufwand), wobei dort um ziemlich große Datenmengen und kompiziertere DB-Abfragen ging).

XML-Dokumente _zu_generieen_ und diese via XSLT zu transformieren stellt aber einen Overhead dar.

Das kann ich aus Praxiserfahrung nicht bestätigen. Jedoch mag deine Aussage bei einer kleinen privaten HP mit nur wenigen Daten zutreffen.

Zudem stehen im PHP seit Version 5 - statt Umwege über zu installierenden Pakages (oder Moduls, die man ohne Zugrifft auf das OS des Server nicht installieren kann)  - mit simpleXML oder libxml und libxslt verschiedene eingebaute Funktionen zur Verfügung.

Vorsicht!
Diese sind standardmäßig zwar aktiviert, die entsprechenden Bibliotheken müssen dennoch vorhanden sein, was ein entsprechenden Zugriff auf das OS auf den (hoffentlich) beflissenen Admin verschiebt. Es sind auch in Version 5 nur Erweiterungen PHPs und müssen nicht zur Verfügung stehen. Aber ich denke, wir sind uns darüber einig, das bereits implementierten Funktionen aus Gründen der Performanz immer den Vorrang vor in PHP programmierten Funktionen zu geben ist.

Stimme dir zwar zu, aber ich halte es für wahrscheinlicher, dass PHP mit -with-xsl[=DIR] konfiguriert wird, als dass für ein Apache (vor allem ein 2-er) mod-xslt2 installiert und kompiliert wird. Dabei benötigt mod-xslt2 ebenfalls ein (vor)installiertes libxml2 und libxslt (nebst anderen Sachen), also kann das auch kein Argument sein.

Auch wenn dies etwas viel verlangt sein mag, aber selbst Datenbankabfragen - ja jede Erweiterung PHPs, läßt sich weitestgehen durch die Mittel PHPs (als Programmiersprache) nachbilden und stellen im eigentlichen Sinne nur nette Hilfsmittel dar.

Das mag man so oder so sehen. Aber ich zweifle daran, dass ein Admin für einen Kunden mod-xslt2 für Apache kompiliert (und schon gar nicht mit besonderen Sachen wie MXSLT_DISABLE_SIGNATURE)

Grüße
Thomas

[XaraX]

Re:

Gut, wenn man nur von einem "Daten aus der DB --> HTML" ausgeht, _mag_ der Weg über XML/XSLT (also "Daten aus der DB ---> XML/XSLT --> HTML") als ein Umweg erschienen. Es kommt aber auf die Daten und auf die Ausgabe an.
In so einem Fall ist oft ein ziemlicher Arbeit das Ausgabescript zu schreiben (mit all dem HTML etc. drinn) und bei Änderungen muss dieses immer wieder angefasst werden.

Ich bitte Dich! ;)
Du wirst doch sicher nicht HTML und PHP in einer Datei haben...

Beispiel:

  
$a=array(  
    '%{Datensatz1}',  
    '%{Datensatz2}',  
    '%{Datensatz3}',  
    '%{Datensatz4}',  
    '%{Datensatz5}',  
    '%{Datensatz6}',  
    '%{Datensatz7}'  
   );  
$b=hole_daten_aus_db();  
$b=mach_array_draus($b);  
  
echo str_replace($a,$b,file_get_contents('xyz.tpl'));  

xyz.tpl:

  
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">  
<html>  
<head>  
 <title>%{Datensatz1}</title>  
 <link href="%{Datensatz2}" type="text/css" rel="StyleSheet">  
</head>  
<body>  
 <h1>%{Datensatz1}</h1>  
 <p>%{Datensatz3}</p>  
 <!-- usw. -->  
</body>  
</html>  

Davon abgesehen ist hierbei der Aufwand m. E. geringer, als das dynamische erstellen von XML.

Da sind zwei Scripte die jeweils nur etwas bestimmtest tun, einfacher zu schreiben und auch zu verwalten. So ein Last auf der Serverseite verursacht das nicht (wir haben mal in einem Projekt zu dieser Frage sogar Benchmark-Tests gemacht (auch hinsichtlich Wartbarkeitsaufwand), wobei dort um ziemlich große Datenmengen und kompiziertere DB-Abfragen ging).

Das überrascht mich. Hast Du eventuell noch ein paar Zahlen im Kopf (ich lerne immer gerne dazu)?

XML-Dokumente _zu_generieen_ und diese via XSLT zu transformieren stellt aber einen Overhead dar.

Das kann ich aus Praxiserfahrung nicht bestätigen. Jedoch mag deine Aussage bei einer kleinen privaten HP mit nur wenigen Daten zutreffen.

Das hat nichts mit klein und groß zu tun, da der Mehraufwand sich proportional verhalten sollte.

Gruß aus Berlin!
eddi

[Thomas J.S.]

Hallo eddi,

Gut, wenn man nur von einem "Daten aus der DB --> HTML" ausgeht, _mag_ der Weg über XML/XSLT (also "Daten aus der DB ---> XML/XSLT --> HTML") als ein Umweg erschienen. Es kommt aber auf die Daten und auf die Ausgabe an.
In so einem Fall ist oft ein ziemlicher Arbeit das Ausgabescript zu schreiben (mit all dem HTML etc. drinn) und bei Änderungen muss dieses immer wieder angefasst werden.

Ich bitte Dich! ;)
Du wirst doch sicher nicht HTML und PHP in einer Datei haben...

_Ich_ wohl kaum ;-)

(wir haben mal in einem Projekt zu dieser Frage sogar Benchmark-Tests gemacht (auch hinsichtlich Wartbarkeitsaufwand), wobei dort um ziemlich große Datenmengen und kompiziertere DB-Abfragen ging).

Das überrascht mich. Hast Du eventuell noch ein paar Zahlen im Kopf (ich lerne immer gerne dazu)?

Leider nein, ist auch schon ... 1 .. 1,5 Jahre her (*wie die Zeit vergeht!*).
Es ging damals zwar um JSPs, aber vom Prinzip her um dieselbe Fragestellung.
Daten aus der DB und aus statischen Dateien holen und am Ende HTML (und PDF und Excel) zu haben. Wie gesagt, es waren aufwendigere Sachen, wo in einem Datensatz mehrere Dutzend Informationseinheiten gekommen sind und wo die JSPs auch schon einige hundert Zeilen hatten (Berechtigungsprüfungen, welchen Teil der Daten darf der User sehen etc.). Am Ende war es aber eindeutig, dass es  - ich sage mal salopp - einfacher war, ein XML zu generiren und dann das durch die XSL-Transformation zu jagen, als die andere Alternativen.

... Ich habe jetzt paar Zahlen, aber ich denke nicht, dass sie dir viel sagen werden, da ich jetzt bestimmte Sachen nicht mehr weiß (Serverausstattung etc.) und bei diesen Daten geht es um die Ausgabe für eine HTML-Seite mit nur wenigen DB-Abfragen (14ms). Der XSLT-Proz. ist Xalan, das generierte XML war in diesem Fall etwa 129KB groß.
MEMORY: At begin of XSLTControl / Used: 75,502kB
Stylesheet-Compilation / 578ms
  - kompiliert wird nur dann, wenn an einem der beteiligten XSLTs seit dem letzten Aufruf was geändert hat, sonst entfällt dieser Teil. Nach einem neuen Aufruf der Seite (cacheing ausgeschaltet, war diese Zeit 1ms)
XSL-Transformation  / 49ms
Parsing Control / 132ms
Load of all Files / 53ms (statische XML-Dateien)
Load & execute all Java-Classes / 62ms
XSLT-Compile & Transform / 637ms
Total time of XSLTControl / 910ms
MEMORY: At end of XSLTControl / Used: 88,173kB

Also die reine Transformationszeit für die 129KB großes XML war 49ms. (üblicher waren aber XMLs bis zu 300-800KB, zum Vergleich: die aktuelle index.xml des Forums ist 729KB)

Grüße
Thomas