Daten eingewickelt

XML (Extensible Markup Language) ist auf dem besten Wege, den Umgang mit Daten aller Art zu verändern. Es nutzt für die Produktion dynamischer Seiten vorzugsweise ein Publishing Framework. Davon gibt es inzwischen einige: AxKit in Perl [1], Zope als Vertreter der Python-Fraktion sowie Cocoon, Bestandteil des XML Apache Project und in Java geschrieben. Bei xmlsoftware.com (alle genannten URLs enthält der Kasten ‘Online-Ressourcen’) finden sich weitere - freie wie kommerzielle. Cocoon empfiehlt sich aus mehreren Gründen:

• Implementierung der W3C-Standards;
• hoher Reifegrad und gute Stabilität;
• bietet eine Reihe nützlicher Eigenschaften;
• unterstützt verschiedene XML-Parser und -Prozessoren;
• verhältnismäßig problemlos in den Apache-Webserver zu integrieren;
• von Cocoon erzeugte Websites im Netz.

Das SQL-Modul von Cocoon benutzt JDBC für den Datenbankanschluss. So ist jedes DBMS einsetzbar, das über eine entsprechende Schnittstelle verfügt. Hier wurde PostgreSQL 7.x gewählt, weil es sich von allen Open-Source-Datenbanken am ehesten mit den professionellen vergleichen lässt, was Skalierbarkeit und Funktionsumfang angeht.

Analog zu LAMP für HTML wäre also LAPToC die Produktionsumgebung für XML: Linux, Apache, PostgreSQL, Tomcat und Cocoon. Sein Funktionsumfang deckt viele Anforderungen an Erhebung, Transport, Speicherung, Transformation und Präsentation von Daten ab, wie sie das Internet und andere verteilte Strukturen stellen. Zur Installation von Cocoon standalone auf Tomcat und zusammen mit Apache siehe ‘Installation von Cocoon’.

Eine funktionierende XML-Produktionsumgebung steht nach der Einrichtung von Cocoon zur Verfügung. Als nächstes wird der Zugriff auf PostgreSQL erfolgen. Um Fehler zu vermeiden beziehungsweise besser orten zu können, finden Installation und Konfiguration Schritt für Schritt statt: Zugriff auf PostgreSQL über die Kommandozeile, via JDBC und schließlich per SQL-Modul von Cocoon.

Datenbankanbindung für Cocoon

Voraussetzung: PostgreSQL ist installiert, vorzugsweise in Version 7.x. Sein übliches Installationsverzeichnis ist /usr/local/pgsql. Als erstes wird eine Datenbank (beispielsweise xml) benötigt, die dem Benutzer gehört, der auch Apache, Tomcat und Cocoon betreibt. Für Testzwecke kann das ruhig root sein, im Produktionsbetrieb sollte man dafür einen Benutzer mit möglichst wenigen Rechten verwenden. Diese Datenbank muss wenigstens eine Tabelle enthalten:

createdb xml
# psql
=> CREATE TABLE adressen (
name CHAR(30), vorname CHAR(30),
plz CHAR(5), ort CHAR(20) );
INSERT INTO adressen VALUES (
'Mustermann','Renate',
12345', 'Oggersheim' );

Mit select * from adressen; lässt sich im PostgreSQL-Monitor prüfen, ob alles funktioniert hat. Nun ist von der PostgreSQL-JDBC-Homepage der Treiber herunterzuladen nach (zum Beispiel) /usr/local/pgsql/jdbc/jdbc7.0-1.1.jar. Damit PostgreSQL auf TCP/IP-Aufrufe hört, die JDBC und das Tcl-Frontend PgAccess benutzen, muss in /etc/rc.d/initd/postgres die Zeile

PGOPTS="-i"

eingefügt werden. Danach erfährt PostgreSQL, dass JDBC es benutzen darf. Dazu ist in /usr/local/pgsql/data/pg_hba.conf diese Zeile einzutragen:

host xml 192.168.128.125  255.255.255.0 trust

‘host’ in der ersten Spalte steht für den Zugang über IP-Sockets, die zweite Spalte enthält den Namen der Datenbank, es folgen die erlaubte TCP/IP-Adresse, deren Maske und die Authentifizierungsmethode. Die neue Einstellung ist wirksam, nachdem man den Datenbankserver im Verzeichnis /usr/local/pgsql/bin mit pg_ctl angehalten und mit postmaster -i wieder gestartet hat. Ab dem nächsten Boot benutzt PostgreSQL sie automatisch.

XML und XSL für SQL

Zum Testen der JDBC-Schnittstelle auf Funktionsfähigkeit dient ein kurzes Java-Programm (siehe Listing 1), das die zuvor erzeugte Tabelle anspricht. Nach seiner Übersetzung ist es mit java Sample zu starten.

import java.sql.*;

public class Sample {

  public static void main (String[] args) 
    throws SQLException, ClassNotFoundException {
    
    // load JDBC driver
    Class.forName("org.postgresql.Driver"); 

    // establish a connection with the desired database
    Connection db = 
      DriverManager.getConnection(
        "jdbc:postgresql://localhost/xml",
        "username", 
        "passwort");

    // set up a query to run
    PreparedStatement st = 
       db.prepareStatement("select * from adressen");

    // run the query to produce a ResultSet
    ResultSet rs = st.executeQuery();
    int numCols  = rs.getMetaData().getColumnCount();

    // print out the contents of the ResultSet
    while (rs.next()) {
      for (int j=1; j <= numCols; j++) 
    System.out.print(rs.getString(j) + "  ");
      System.out.println();
    }

    // close the resources 
    rs.close();
    st.close();
    db.close();
  }
}
Ein kurzes Java-Programm 
testet die Funktionsfähigkeit 
des PostgreSQL-JDBC-Treibers.

Damit JDBC für Cocoon erreichbar ist, muss jdbc7.0-1.1.jar in $TOMCAT_HOME/lib stehen. Es folgt die Konfiguration Cocoons für die Benutzung seines SQL-Moduls, indem in $TOMCAT_HOME/webapps/cocoon/WEB-INF/cocoon.properties, sofern notwendig, die Zeile

processor.type.sql =
  org.apache.cocoon.processor.sql.SQLProcessor

eingefügt wird. Anschließend muss man Tomcat in $TOMCAT_HOME/bin mit ./shutdown.sh anhalten und mit ./startup.sh wieder starten, damit er das zusätzliche .jar-Archiv in seinen Classpath einbindet. Zum Testen des Moduls kann man nun eine kleine XML-Datei (siehe Listing 2) mit zugehörigem Stylesheet (Listing 3) benutzen, entlang den Anweisungen in $COCOON_HOME/docs/sql.html. Sind beide nach $TOMCAT_HOME/webapps/cocoon ge-stellt, kann man sie im Browser mit http://localhost/cocoon/sql01.xml aufrufen.

<?xml version="1.0" encoding="ISO-8859-1" standalone="no" ?>
<?xml-stylesheet href="sql01.xsl" type="text/xsl"?>

<?cocoon-process type="sql"?>
<?cocoon-process type="xslt"?>

<!DOCTYPE page SYSTEM "sql.dtd">

<page>

<!-- root-element -->

  <connectiondefs>
      <!-- Name DB-Verbindung -->
    <connection name="foo">
      <driver>org.postgresql.Driver</driver>
      <!-- URL DB-Verbindung -->
      <dburl>jdbc:postgresql://localhost/xml</dburl>
      <username>root</username>
  <password>fritz</password>
  </connection>  
  </connectiondefs>
  
  <tab>
    <query connection="foo">  <!-- Aufruf DB-Verbindung -->
      select * from adressen  <!-- DB-Abfrage -->
    </query>
  </tab>
   
</page>

<?xml version="1.0" encoding="ISO-8859-1"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">

<xsl:template match="page">

  <!-- Anweisung zur Ausgabe von html -->
  
     <xsl:processing-instruction name="cocoon-format">
    type="text/html"
  </xsl:processing-instruction>
  
  <!-- html-Körper -->
  
     <html>
      <head>
         <title>
           PostgreSQL Search Results
         </title>
      </head>
      <body bgcolor="#FFF8DC">
      <font face="helvetica">
        <h1>PostgreSQL</h1>
      
        <!-- übernimmt Inhalte der .xml-Datei -->
        
           <xsl:apply-templates/>
      </font>
      </body>
   </html>
</xsl:template>
    
<!-- wählt das selbstdeklarierten Tag 'tab' aus -->
  
<xsl:template match="tab"> 
   <table border="2" cellspacing="0" cellpadding="6"
      bordercolor='#000099' bgcolor="#CCCCFF">
    <tr>
      <th>Name</th>
      <th>Vorname</th>
      <th>PLZ</th>
      <th>Ort</th></tr>
      
        <!-- übernimmt Inhalte von 'tab' und damit
        das Ergebnis der Datenbankabfrage -->
        
        <xsl:apply-templates/>
  </table>
</xsl:template>


<!-- Formatiert das Ergebnis der Datenbankabfrage -->

<xsl:template match="ROW">  
  <tr>    
     <td><xsl:value-of select="name"/></td>
     <td><xsl:value-of select="vorname"/></td>
     <td><xsl:value-of select="plz"/></td>
     <td><xsl:value-of select="ort"/></td>   
  </tr>
</xsl:template>

</xsl:stylesheet>

Ist alles in Ordnung, spricht die XML-Datei die oben angelegte Tabelle adressen an. Erst die Antwort der Datenbank leiten Apache/Tomcat an das dazugehörige Stylesheet weiter, das es nach HTML wandelt. Im Vergleich zur Anbindung und Ausgabe mit anderen Methoden, ob nun über ein Servlet, Perl oder PHP, ist diese Methode komfortabler und weniger arbeitsaufwendig.

Nach der Pflicht die Kür: Mit Cocoon und seinem SQL-Modul soll ein interaktiver Datenbankzugang per Browser realisiert werden. Es handelt sich hierbei um eine Three-Tier-Architektur mit dem Browser als Frontend, Apache, Tomcat und Cocoon als Middleware und PostgreSQL als Backend. Zur Formularauswertung dient PHP4.

Cocoons SQL-Modulin Aktion

Zunächst sieht alles aus wie beim Test: Die Datei dbformular.xml nimmt die Angaben für das Formular auf. Das könnte an dieser Stelle auch in HTML geschehen; XML ist aber genauso gut geeignet, und es kann hier schon seine Vorzüge ausspielen. Cocoon formatiert das Formular via dbformular.xsl und liefert es im HTML-Format an den Browser aus. Die Eintragungen schickt der Webserver an ein PHP-Skript, das sie als Variable entgegennimmt und die eigentliche XML-Datenbankabfrage dbabfrage.xml schreibt, inklusive Authentifizierungsdaten und SQL-Anweisung.

<?xml version="1.0" encoding="ISO-8859-1" standalone="no" ?>
<?xml-stylesheet href="dbformular.xsl" type="text/xsl"?>
<?cocoon-process type="xslt"?>


<page>
  <form>
    <aut>
      <input name="db" type="text" size="30">
        Name der Datenbank: 
      </input>
      <input name="user" type="text" size="30">
        Benutzername: 
      </input>
      <input name="password" type="password" size="30">
        Passwort: 
      </input>
    </aut>
    <inhalt>
      <textarea  name="sql"  type="text" rows="10" cols="30">
        SQL-Anweisung: 
      </textarea>
    </inhalt>    
  </form>
</page>

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="/">   
     <xsl:processing-instruction name="cocoon-format">
       type="text/html"
     </xsl:processing-instruction>
     <html>
      <head>
         <title>
            PostgreSQL Abfrage
         </title>
      </head>

  <body bgcolor="white">
  

  <!-- HTML-Ausgabe -->

    <center>
      <p>   
        <br></br>
      </p>
      <p>
        <br></br>
      </p>
  
      <h1>PHP-Test</h1><br></br>
      <p>
        Bitte geben Sie Ihre SQL-Anfrage in die Maske ein.
      </p>
      <xsl:apply-templates select="form"/>
      <xsl:apply-templates/>
    </center>
  </body>
  </html>
</xsl:template>



<xsl:template match="form">
  <table>
    <form action="http://127.0.0.1/php/uebung1/phpxml03.php" method="post">
      <xsl:apply-templates select="aut"/>
      <xsl:apply-templates select="inhalt"/>
    <tr>
      <td></td>
      <td>
      <p></p><p>
      <center>
      <input type="submit" value="PHP-Eintrag abschicken"/>
      </center>
      </p>
      </td>
    </tr>
    </form>
  </table>
</xsl:template>

<xsl:template match="aut">    
    <xsl:for-each select="input">
    <tr>
      <td><xsl:value-of select="."/></td>
      <td>
        <input>
          <xsl:attribute name="name">
            <xsl:value-of select="@name"/>
          </xsl:attribute>
          <xsl:attribute name="TYPE">
            <xsl:value-of select="@type"/>  
          </xsl:attribute>
          <xsl:attribute name="SIZE">
            <xsl:value-of select="@size"/>
          </xsl:attribute>    
        </input>
      </td>
    </tr>
    </xsl:for-each>      
</xsl:template>

<xsl:template match="inhalt">  
  <xsl:for-each select="textarea">
    <tr>
      <td>
        <xsl:value-of select="."/>
      </td>
      <td>
        <textarea>
          <xsl:attribute name="name">
            <xsl:value-of select="@name"/>
          </xsl:attribute>
          <xsl:attribute name="TYPE">
            <xsl:value-of select="@type"/>  
          </xsl:attribute>
          <xsl:attribute name="rows">
            <xsl:value-of select="@rows"/>  
          </xsl:attribute>
          <xsl:attribute name="cols">
            <xsl:value-of select="@cols"/>
          </xsl:attribute>  
        </textarea>
      </td>
    </tr>
  </xsl:for-each>    
</xsl:template>

</xsl:stylesheet>

<?xml version="1.0" encoding="ISO-8859-1" standalone="no" ?>  
<?xml-stylesheet href="dbabfrage.xsl" type="text/xsl"?>
<?cocoon-process type="sql"?>
<?cocoon-process type="xslt"?>
  <page>
      <connectiondefs>
        <connection name="foo">
          <driver>org.postgresql.Driver</driver>
          <dburl>jdbc:postgresql://localhost/php</dburl>
          <username>root</username>
      <password>fritz</password>
      </connection>  
      </connectiondefs> 
      <tab>
        <query  connection="foo">
    SELECT * FROM demo
      </query>
      </tab>  
  </page>

<?xml version="1.0" encoding="ISO-8859-1"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">

<xsl:template match="page">

  <!-- Anweisung zur Ausgabe von html -->
  <xsl:processing-instruction name="cocoon-format">
    type="text/html"
  </xsl:processing-instruction>
  
  <!-- html-Körper -->
  
     <html>
      <head>
         <title>
           PostgreSQL Search Results
         </title>
      </head>

      <body bgcolor="#FFF8DC">
      <font face="helvetica">
        <h1>PostgreSQL</h1>
        <!-- übernimmt Inhalte der XML-Datei -->
        <xsl:apply-templates/>
      </font>
      </body>
   </html>
</xsl:template>
  
  
<!-- wählt das selbstdeklarierten Tag 'tab' aus -->
  
<xsl:template match="tab"> 
    <xsl:apply-templates/>
</xsl:template>


<!-- Formatiert das Ergebnis der Datenbankabfrage -->

<xsl:template match="ROW">  
  <pre>    
     <xsl:apply-templates/>   
  </pre>
</xsl:template>

</xsl:stylesheet>

Per Refresh aktiviert dieses PHP-Skript dbabfrage.xml, das der Webserver auswertet und die Antwort mit dem zugehörigen XSL-Stylesheet dbabfrage.xsl formatiert wiederum an den Browser ausliefert. Das in dbabfrage.xsl verwendete <pre> hat zwar den Vorteil, dass es alles ausgibt, was die Datenbankabfrage ergibt; aber optisch ansprechend ist es nicht gerade. Mit den Spaltennamen der zurückgelieferten Tabelle lässt sich eine beliebige Formatierung erstellen, zum Beispiel so:

<xsl:template match="ROW">
    <tr>
      <th><b>Name</b></th>
      <th><b>Vorname</b></th>
       <th><b>PLZ</b></th>
       <th><b>Ort</b></th>
     </tr>
     <tr>    
       <td><xsl:value-of select="name"/></td>
       <td><xsl:value-of select="vorname"/></td>
       <td><xsl:value-of select="plz"/></td>
       <td><xsl:value-of select="ort"/></td>
    </tr>
</xsl:template>

Administratorrechte vorausgesetzt, stehen auf diese Weise über den Browser alle Funktionen zur Verfügung, die der PostgreSQL-Monitor bietet. Darüber hinaus sind über das SQL-Modul alle Abstufungen in der Berechtigung für Datenbankzugriffe benutzbar, die auch PostgreSQL bereitstellt.

Das vorgestellte Beispiel ist nur eine Möglichkeit, das SQL-Modul von Cocoon zu nutzen. Im oberen Teil von dbabfrage.xml ist ein Datenbank-Handler formuliert, der im weiteren Verlauf der XML-Datei an beliebiger Stelle mit

<query connection="foo"></query>

aufrufbar ist. Damit stehen die Datenbankfunktionen jederzeit zur Verfügung. Darüber ließen sich die Verlinkung innerhalb der gesamten Site regeln oder Sammlungen von Webadressen pflegen, Kataloge oder Shopsysteme aufbauen und dergleichen.

PHP hilft hier, mit wenig Aufwand die benötigte XML-Datei zu erzeugen; andere Wege sind denkbar. Beispielsweise könnte man die Authentifizierung festlegen und die SQL-Anfrage mit einem beliebigen CGI-Script in eine eigene Datei schreiben, die per DTD über eine externe Entity referenziert wird. In dbabfrage.xml wäre die Abfrage so einzubinden:

<query  connection="foo">
    &pg;
</query>

Darüber hinaus bietet Cocoon selbst mit dem XSP-Modul ein umfangreiches und mächtiges Tool für interaktive und dynamische Webseiten an.

Für alle Bestandteile der hier beschriebenen XML-Produktionsumgebung stehen demnächst zum Teil größere Versionssprünge an, deren Alpha- oder Beta-Vorgänger bereits im Netz stehen: Apache 2, Tomcat 4.0, PostgreSQL 7.1 und Cocoon 2.

Apache und Tomcat hat iX schon besprochen [[#literatur 2]]. Das vor kurzem freigegebene PostgreSQL 7.1 verabschiedet sich endlich von der bisherigen Beschränkung der Datensatzlänge, sodass BLOBs ohne die bisherigen Einschränkungen verwendbar sind.

Next Generation: SAX statt DOM

Cocoon 2 ist ein entscheidender Schritt hin zur Eignung für den harten Produktionseinsatz. Denn so gut Version 1.8 schon funktioniert, ihr Tempo kann noch nicht überzeugen. Das liegt in der Geschichte begründet: Ursprünglich schrieb Stefano Mazzocchi Cocoon als Werkzeug, um die XML-Spezifikationen ausprobieren zu können. Für diesen Zweck war Performance nebensächlich, außerdem wurden schon existierende XML-Tools von Cocoon integriert und damit deren Restriktionen.

Als Basis für Cocoon 1.x diente DOM-Level 1 (Document Object Model), ein passives API. Seine Leistung ist dadurch beschränkt, dass zunächst das gesamte Dokument im Speicher stehen muss, bevor man darauf zugreifen kann. Außerdem hat DOM einen großen Overhead: Für eine 100-KByte-Datei kann es durchaus 1 MByte Speicherplatz verbrauchen. Ziel von Cocoon 2 ist es, mehrere 100 MByte große Dokumente gleichzeitig in der JVM bearbeiten zu können und dazu nur wenige MByte Overhead zu benötigen. Dazu war ein ereignisorientiertes API erforderlich. Dieses API ist SAX, (Simple API for XML). Obwohl es keine Empfehlung des W3C ist, unterstützten es die meisten Java-XML-Parser, so auch der von Cocoon eingesetzte Xalan.

SAX verarbeitet XML als einen Strom von Ereignissen. Das bringt erheblich kürzere Bearbeitungszeiten, aber auch Nachteile mit sich: Weil immer nur ein Teil des Dokuments im Speicher präsent ist, verursachen Suchfunktionen, wie sie beispielsweise bei Referenzen innerhalb der Datei anfallen, nicht unerhebliche Schwierigkeiten. Die Verwendung von SAX erlaubt es Cocoon 2, Geschwindigkeit und Ansprechbarkeit durch mehrere Maßnahmen zu verbessern:

• Inkrementelle Verarbeitung: Der Prozessor erzeugt die Antwort, während er das Dokument noch verarbeitet, und liefert sie sofort aus. Bislang geschah das erst, sobald das gesamte Dokument fertig bearbeitet war. Für Fälle, in denen das nicht möglich ist, etwa beim Sortieren von Elementen, stellt Cocoon 2 den nötigen internen Speicher bereit, bis es die Operation ausführen kann. Damit ist der oben erwähnte Nachteil von SAX ausgeglichen. Selbst in diesen Fällen ist die Leistung besser, weil die internen Speicherfunktionen optimiert sind.
• Reduzierter Speicherverbrauch: Durch das stückweise Verarbeiten und Ausliefern des Dokuments besteht keine Notwendigkeit, es vollständig im Speicher zu halten.
• Bessere Skalierbarkeit: Der geringere Bedarf an Speicher für jede einzelne Operation erlaubt mehr gleichzeitige Operationen.
• Optimierung von Code: Moderne JVMs nutzen das Konzept von Hotspots. Das sind häufig vorkommende Codeteile, deren Optimierung die Leistung wesentlich verbessert. Mit der ereignisbasierten Verarbeitung lassen sich diese Hotspots leichter entdecken und optimieren als mit einer speicherbasierten.
• Reduzierte Garbage Collection: Es entsteht weniger abgearbeiteter Code, der noch im Speicher bleiben muss. Das verbessert ebenso die Ausnutzung vorhandenen Speichers, wie es die CPU entlastet.

Neben diesen Verbesserungen bietet Cocoon 2 eine leichtere Verwaltung der Website. Zentralstelle dieses verbesserten Managements wird XSP sein, die eXtensible Server Pages, eine Weiterentwicklung von JSP für den Einsatz unter XML mit der hier üblichen strengen Trennung von Inhalt und Darstellung. Schon Cocoon 1 enthält ein XSP-Modul mit weit reichenden Funktionen und Tag-Libs; für die Version 2 soll das noch ausgebaut werden und die Verarbeitung langer URIs erleichtern.

Fazit

LAPToC - Linux, Apache, PostgreSQL, Tomcat und Cocoon - ist als XML-Produktionsumgebung schon heute zuverlässig und stellt eine große Anzahl von Funktionen zur Verfügung. Dem hier ausführlich behandelten SQL gesellen sich noch Module hinzu für LDAP, XSP und XML-Fragments sowie Tag-Libraries für XSP und SQL.

Alle Bestandteile sind Open Source und halten sich eng an die Empfehlungen des W3C und des ANSI. Linux als Betriebssystem ist nicht obligatorisch, von allen Programmen sind Versionen für andere Betriebssysteme (Windows NT, Unix) erhältlich.

Ebenfalls für alle Bestandteile gilt, dass sie schon einige Jahre in Gebrauch sind und ihre Tauglichkeit unter Beweis gestellt haben. Ihre rührige Entwicklergemeinde lässt es wahrscheinlich erscheinen, dass auch in Zukunft die Entwicklung weitergeht und die Quellen frei zugänglich bleiben. Investitionssicherheit ist gerade bei einer aus mehreren unabhängigen Komponenten aufgebauten Architektur entscheidend.

Andreas Popper
ist Agraringenieur, arbeitet freiberuflich als Webentwickler und setzt seit zwei Jahren XML ein.

Literatur

[1] Henning Behme; XML-Programmierung; Mutabor; XSLT-Tutorial III: dynamisches XML mit AxKit

[2] Stefan Borggraefe; Webserver; Old Threadhand; Neuerungen in Apache 2.0; iX 2/2001, S. 42

<!ENTITY pg SYSTEM 
"http://localhost/cocoon/cocoon_sql/pg01.txt">

<!ELEMENT page (connectiondefs, tab)+>
<!ELEMENT connectiondefs (connection)+>
<!ELEMENT tab (query)+>
<!ELEMENT connection (driver, dburl, username, password)+>
        
<!ATTLIST connection 
name         (foo) #IMPLIED>
                
<!ELEMENT driver (#PCDATA)>
<!ELEMENT dburl (#PCDATA)>
<!ELEMENT username (#PCDATA)>
<!ELEMENT password (#PCDATA)>

<!ELEMENT query (#PCDATA)>

<!ATTLIST query 
connection   (foo) #IMPLIED >

<?xml version="1.0"  encoding="ISO-8859-1"?>
<?xml-stylesheet href="../cocoon.xsl" type="text/xsl"?>
<?cocoon-process type="xslt"?>

<satzspiegel>
<code>
<![CDATA[
<html>
<head>
  <meta http-equiv="refresh" content="1; 
    URL=http://localhost/cocoon/xml/uebung/php/dbabfrage.xml">
  
  <title>PHP-Eintrag aus XML</title></head>
<body>
<center>
<p> <p>
<h1>Verbindung zu PostgreSQL</h1>
<?php

// Schaun, ob überhaupt was eingetragen wurde
    
if(isset($sql)){
  print "<p><b>Ihre Anfrage wird bearbeitet.<br>
    Bitte einen Moment Geduld</b></p>";
        }
?>
</center>
        
<?php        
// Hierhin wird die eigentliche Datenbankabfrage
// mit dem sql-Modul geschrieben
        
$datei = '/usr/local/jakarta/dist/tomcat/webapps/cocoon/xml/
uebung/php/dbabfrage.xml'; 

$fpw = fopen($datei,"w");  // öffnet und löscht vorm Schreiben
$fpa = fopen($datei,"a");  // öffnet und hängt an beim Schreiben
         
// xml-File zur Datenbankabfrage vial Cocoons Sql-Modul
// 1.) Übernahme der Authentifizierung
        
$file1 = '<?xml version="1.0" 
   encoding="ISO-8859-1" standalone="no" ?>    

<?xml-stylesheet href="dbabfrage.xsl" type="text/xsl"?>
<?cocoon-process type="sql"?>
<?cocoon-process type="xslt"?>
    <page>
    <connectiondefs>
    <connection name="foo">

    <driver>org.postgresql.Driver</driver>
    <dburl>jdbc:postgresql://localhost/'.$db.'</dburl>
        <username>'.$user.'</username>
            <password>'.$password.'</password>
    </connection>    
      </connectiondefs> 
     <tab>
        <query  connection="foo">
        ';    
            
        // 2.) sql-Kommando; 
        // Slashes müssen explizit entfernt werden
                
        $file2 = stripSlashes($sql);    
    
        // 3.) restlicher Teil des xml-Files
        
        $file3 = '
            </query>
          </tab>  
    </page>'
        ;
        
        // Schreiben des .xml-Files
        
        fwrite($fpw,"");  // löscht alten Inhalt                
        fwrite($fpa,"$file1");
        fwrite($fpa,"$file2");
        fwrite($fpa,"$file3");
        fclose($fpa);
        fclose($fpw);            
?>
</body>
</html>
]]>
</code>
</satzspiegel>