Halihallo Eisbär
Mit einigen Anpassungen nicht. Der ParseTree liegt ja im Speicher des Daten-Scripts. Du musst dein XPath-Modul nur so abändern, dass es durch das Socket kommuniziert und ein anderes XPath-Modul im Daten-Script aufruft, der den Node zurückliefert (ohne das XML neu zu parsen => das XPath Modul muss auf den Memory-ParseTree von XML::DOM zugreifen).
Aktuell setze ich das Modul XML::Parser mit Style=Object ein, das ein etwas merkwürdiger Objektbaum zurückliefert.
Darüber habe ich eine eigene XML-Klasse gestrickt, welche eine Zugriff auf die XML-Elemenet mit Methoden wie getNodeByID(), getNodesByElement(), etc. zurückliefert.
Zufällig bin ich nun aber über das Modul XML::XPath gestolpert, das noch viel umfangreicher Funktionalität bietet und vor allem schon fertig ist. Dieses Modul verwendet aber einen eigenen Parser (XML::XPath::Parser). Wie schnell dieser ist, weiss ich aktuell noch nicht, aber er basiert ebenso wie XML::Parser auf dem Expat-Parser.
Also an Expat kann die Performance nicht scheitern, da dieser mit C programmiert ist. Das Problem der Performance ist, wie die geparsten Daten abgebildet werden und wie effizient darauf zugegriffen werden kann.
Wo bekomme ich eigentlich das Modul XML::SAX her? Auf CPAN habe ich es nicht gefunden.
Was? - Dort muss es aber sein ;)
http://www.cpan.org/authors/id/M/MS/MSERGEANT/
Die XML-Daten werden durch den übergelagerten Daten-Server geparst der resultierende Tree im Speicher gehalten.
Nun kommuniziere ich von den Darstellungsskripts mit XPath-Anweisungen (sind ja relativ kurze einfache Befehle, bzw. Strings)
zum Datenserver.
Falls ich alle Anfragen zum Datenserver so formuliere, dass er mir nur Attributwerte oder Elementinhalte (Text) zurückliefern muss, dann kann ich mir die Seriealisierung tatsächlich sparen. Sollte ich aber Auflistungen von Objekten (als Hashes oder Arrays) benötigen, so komme ich um die Serialisierung nicht herum und dies kostet wieder Performance.
Nun, eine gewisse Serialisierung musst du wohl oder übel machen (wenn du auf Arrays oder Hashes zugreifst), aber wenn keine Rekursiven Strukturen dabei sind, ist die Serialisierung denkbar einfach:
%test = ( 'philipp' => 'hasenfratz', 'du' => 'dunachnahme');
=> philipp;hasenfratz;du;dunachname
genau gleich bei arrays. Auch rekursive Datenstrukturen wären denkbar, wenn du die "untergeordneten" ';' kodierst. Das wäre etwas performanter, als einen XML-Parser einzusetzen (ungetestet).
Es ist übrigens nicht schwer, ganze Objekte in der Datenbank abzubilden. Dazu brauchst du nur einen Mapper, der das Objekt in eine relationale Form bringt... Oder vielleicht hast du ja gar eine OODBMS ;)
Hab ich auch schon gemacht und funktioniert prima.
Eine RDBMS setze ich auch als persistener Datenspeicher ein. XML ist nur die Import-/Export-Schnittstelle zu Fremdsystemen.
Im ersten Schritt werde ich alle Objekte bei jedem Skriptaufruf aus der Datenbank laden.
Die Lösung mit dem Datenserver und der Socketkommunikation hebe ich mir für Installationen mit höheren Anforderungen auf.
Trotzdem vielen Dank für die Anregungen.
Aber bitte.
Viele Grüsse
Philipp