[Guradia]

Objekt-Persistenz; PHP Session Fruits

- Von unvollständigen Klassen

PHP bietet uns ein Session-Management. Feine Sache, um Variablen oder auch ganze
Arrays darin abzuladen. Doch leider krankt das System bei Objekten. Nicht etwa,
weil es nicht könnte, sondern einfach, weil PHPs Architektur es nicht hergibt.

Keine Probleme bereiten Objekte aus internen Klassen wie stdClass oder dir. Doch
Objekte in PHP geschriebener Klassen kann das SessionManagement nicht wieder
herstellen. Die Objekte degenerieren hierbei zu "unvollständigen Klassen", die
zwar wie eine stdClass alle Eigenschaften behalten haben, aber um jegliche Methoden
beraubt sind.

Warum dies geschieht ist schnell erklärt, der Quellcode der Klassen ist zum
Zeitpunkt des Aufrufs von session_start() nicht verfügbar und PHP ist nicht bekannt, wie das Objekt
zu rekonstruieren ist. Die Lösung des Problems ist eigentlich sehr simpel. Die
Klassen müssen inkludiert werden, bevor session_start() aufgerufen wird.

Mit wachsendem Ausmaß des Projekts, steigt allerdings auch die Menge der genutzen
Klassen und somit auch der Overhead, der zu inkludierenen Quelldateien. Natürlich
kann man diesen Overhead dahingehen reduzieren, dass nur benötigte Klassen der
Session zur Verfügung gestellt werden, doch zum einen ist dies höchst vermutlich
sehr variabel, zum anderen ein leicht intransparent werdender Verwaltungsaufwand.

- Einsatz für __autoload()

PHP5 bietet allerdings eine gänzlich unscheinbare neue Funktion, die hier so richtig
schön auftrumpfen kann: __autoload(). Der Zweck ist einfach beschrieben: Wird
eine Klasse instanziiert, die nicht deklariert ist, erhält __autoload() deren
Namen als einzigen Parameter. Das ist es eigentlich schon. Was wir nun innerhalb
__autoload() anstellen, bleibt uns überlassen.

Natürlich geht es nun darum, die Quelldatei der vermissten Klasse zu inkludieren.
Da wir als Parameter aber nur den Klassennamen haben, müssen wir von diesem
irgendwie auf die Datei schliessen und diese inkludieren. Hierbei führen uns
viele Wege ans Ziel, im Rahmen des Tutorials werde ich im folgenden aber eine
Möglichkeit mitsamt zugehörendem Layout im Dateisystem vorstellen.

- PHP Session Fruits

Das Layout der Applikation im Dateisystem ist wichtig, um generisch anhand von
Klassennamen deren Dateien finden zu können. Einfach wäre es, alle
Datein in einem Verzeichnis aufzubewaren, und gleich ihrer Klasse zu benennen.
Das verliert aber für die meisten Entwickler sehr schnell an Übersicht.

Eine praktikable Stuktur findet sich in PEAR. Hier werden Klassen thematisch in
Ordnern abgelegt. Diese Ordner finden sich in den Klassennamen wieder:

# Dateien
DB.php
HTML/QuickForm.php
Mail/mime.php

# Klassen
DB
HTML_QuickForm
Mail_mime

Wir imitieren diese Strukur einmal in einer völlig albernen foo/bar-Applikation:

index.php
Foo.php
Foo/Bar.php

index.php sorgt für den Aufruf der Objekte und beinhaltet die __autoload()-Implementation.
Foo.php enthält die Klasse Foo, welche nur einen recht primmitiven Zähler darstelt.
Foo/Bar.php mit Klasse Foo_Bar erweitert Foo um ... noch einen Zähler.
Innerhalb der index.php wird nur Foo_Bar instanziiert, __autoload wird selbständig
beide nötigen Dateien laden.
Ein simples echo triggert __toString(), welches ein paar Informationen ausspuckt,
die verdeutlichen, dass soeben persitente Objekte enstanden sind. Die "PHP Session Fruits" ^^


index.php

PHP-Code:

<?php


/**
 * Übersetzt Klassennamen in einen Pfad und versucht die Klasse zu laden
 * 
 * @param string $ClassName zu ladende Klasse
 */
function __autoload($ClassName)
{
    /* Aufbrechen des Klassennamens anhand von Unterstrichen
     * 
     * Foo resultiert in
     * array {
     *     [0] => 'Foo'
     * }
     * 
     * Foo_Bar resultiert in
     * array {
     *     [0] => 'Foo'
     *     [1] => 'Bar'
     * }
     */
    $ClassName = explode('_', $ClassName);
    
    /* Zusammensetzen zu Verzeichnispfad
     * 
     * Foo wird unverändert wieder zu Foo
     * Foo_Bar heisst nun Foo/Bar
     */
    $ClassName = implode('/', $ClassName);
    
    /* File-Extension angehägt und schon haben wir unsere passende Datei:
     * Foo.php
     * Foo/Bar.php
     */
    require_once $ClassName . '.php';
}

/* Beginn der Session */
session_start();

/* eine kleine Überprüfung, ob das Objekt noch erstellt werden muss */
if (!isset($_SESSION['FooBar']))
    if (!is_object($_SESSION['FooBar']))
        $_SESSION['FooBar'] = new Foo_Bar();

/* Ausgabe des Objekts über __toString() */
echo $_SESSION['FooBar'];

?>

Foo.php

PHP-Code:

<?php

class Foo
{
    protected $WakeUpCounter = 0;
    protected $ConstructCounter = 0;
    
    public function __construct()
    {
        $this->ConstructCounter++;
    }
    
    public function __wakeup()
    {
        $this->WakeUpCounter++;
    }
    
    public function __toString()
    {
        return
            'Foo wurde '.$this->ConstructCounter.' x konstruiert<br />'."\n" .
            'und '.$this->WakeUpCounter.' x aus dem Schlaf gerissen<br />'."\n";
    }
}

?>

Foo/Bar.php

PHP-Code:

<?php

class Foo_Bar extends Foo
{
    protected $BarWakeCounter = 0;

    public function __wakeup()
    {
        $this->BarWakeCounter++;
        parent::__wakeup();
    }
    
    public function __toString()
    {
        return
            parent::__toString() .
            'und hat dabei Bar '.$this->BarWakeCounter.' x nicht weiterschlafen lassen<br />'."\n";
    }
}

?>

[robo47]

Schönes Tutorial, vor allem gut geschrieben wie ich finde. Ich speichere zwar nie irgendwelche Objekte in Sessions, aber jetzt weis ich wenigstens wie ich sauber vorgehen muss wenn ich das wollte.

mfg
robo47

[DasMööp]

Hi,

das hatte ich auch schonmal gefragt aber es wurde abgeraten, frage wo
liegen die Vorteile bei Objecten in Sessions und wenn nicht warum ?

Finde das gehört noch dazu.
(Nein ich wüsste es nicht wirklich)

Aber sehr schön verständlich zu lesen !

[MrNiceGuy]

ICh denke mal, dass der Vorteil einfach darin liegt, dass man den letzten Status des Objektes direkt wiederherstellen kann. Sprich: Eine Datenbank-Verbindung würde bestehen bleiben, bei einer Template-Klasse würden die Templates bereits geladen sein, etc. etc.

[Guradia]

Zitat von DasMööp

das hatte ich auch schonmal gefragt aber es wurde abgeraten, !

Da wüsste ich doch gerne, was du tatsächlich gefragt hast und was dann die begründung war.

Vermutlich deckt sich das ganz gut mit meiner Einleitung ^^

[DasMööp]

Phu ... da bin ich nicht so tief drin hab mich dann umgestellt da es nur ein versuch
war bis dahin kannte ich auch __autoload noch nicht.

Hatte mir selbst eine funktion gebastellt die alle klassen geladen hatte die
vorhanden waren und in $_SESSION['class'][$classname'] gespeichert und
auch so angesprochen wenn ich diese benötigt hatte.
http://forum.developers-guide.net/thread196.html

Muss das hier auch erstmal noch aufarbeiten ...

[Guradia]

Zitat von DasMööp

Hatte mir selbst eine funktion gebastellt die alle klassen geladen hatte die
vorhanden waren und in $_SESSION['class'][$classname'] gespeichert und
auch so angesprochen wenn ich diese benötigt hatte.
http://forum.developers-guide.net/thread196.html

Ahh .. hab den Thread damals gesehen, aber nicht wirklich verstanden, wie du von Sichtbarkeit plötzlich auf Persitenz übergingst ... ^^

[DasMööp]

wie du von Sichtbarkeit plötzlich auf Persitenz übergingst ... ^^

äh was !?

[robo47]

Zitat von MrNiceGuy

ICh denke mal, dass der Vorteil einfach darin liegt, dass man den letzten Status des Objektes direkt wiederherstellen kann. Sprich: Eine Datenbank-Verbindung würde bestehen bleiben, bei einer Template-Klasse würden die Templates bereits geladen sein, etc. etc.

Also die Datenbankverbindugn bleibt würde ich behaupten nur bestehen wenn eh eine persistente verbindung besteht, weil wenn ich

www.php.net/mysql_close

Using mysql_close() isn't usually necessary, as non-persistent open links are automatically closed at the end of the script's execution. See also freeing resources.

http://www.php.net/manual/en/languag....self-destruct

Due to the reference-counting system introduced with PHP 4's Zend Engine, it is automatically detected when a resource is no longer referred to (just like Java). When this is the case, all resources that were in use for this resource are made free by the garbage collector. For this reason, it is rarely ever necessary to free the memory manually by using some free_result function.

Note: Persistent database links are special, they are not destroyed by the garbage collector. See also the section about persistent connections.

Hier stellt sich jetzt die Frage ob PHP erkennt, dass eine Mysql-Klasse mit aktiver Mysql-Verbindung in ner Session gespeichert wird und diese Verbindung dann eben nicht schließt.

Aber ich lasse mich gerne eines besseren belehren

mfg
robo47

[Waq]

Datenbankverbindungen überleben keine Session, auch nicht persistente. Persistenten Verbindungen lassen sich zwar wiederverwenden, allerdings
- muss man dazu ein connect machen, um die persistente Verbindung "auszugraben"
- ist nicht von der Session abhängig, welche Verbindung wiederverwendet wird, sondern vom Apache-Prozess

[MrNiceGuy]

OK, zugegeben: Schlechtes Beispiel mit der DB-Verbindung. Hätte da auch an eine persistente Verbindung gedacht, aber vermutlich wird selbst die beendet beim Beenden des Scripts.

[Lars]

Persistente Verbindungen kann man afaik doch nur auf die harte Tour, also den Prozess killen, beenden.
mysql_close() wirkt jedenfalls nur auf normale Verbindungen.

[Guradia]

Objekte = Datenstrukturen
String/Int/Float = Daten
Dateien/Datenbanken/Sockets etc. = Ressourcen

Session = persistenter Speicher für Daten und -strukturen

Damit dürfte gesagt sein, was in eine Session passt und was nicht.

__wakeup() bietet aber eine Implementationsmöglichkeit, Ressourcen wiederherzustellen.