<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 24249 -->
<!-- Reviewed: no -->
<sect1 id="zend.view.abstract">
    <title>Zend_View_Abstract</title>

    <para>
        <classname>Zend_View_Abstract</classname> ist die Basisklasse auf der
        <classname>Zend_View</classname> aufbaut; <classname>Zend_View</classname> selbst erweitert
        Sie einfach und deklariert eine konkrete Implementation der <methodname>_run()</methodname>
        Methode (welche durch <methodname>render()</methodname> aufgerufen wird).
    </para>

    <para>
        Viele Entwickler finden das Sie <classname>Zend_View_Abstract</classname> erweitern wollen
        um eigene Funktionalitäten hinzuzufügen und daraus folgend in Probleme mit dessen Design
        laufen, welches eine Anzahl an privaten Membern enthält. Dieses Dokument zielt darauf ab
        die Entscheidung hinter diesem Design zu erklären.
    </para>

    <para>
        <classname>Zend_View</classname> ist etwas wie eine Anti-Template Maschine und verwendet
        deswegen <acronym>PHP</acronym> nativ für sein Templating. Als Ergebnis ist alles von
        <acronym>PHP</acronym> vorhanden und View Skripte erweitern Ihre aufrufendes Objekt.
    </para>

    <para>
        Es ist dieser letzte Punkt der relevant für die Design Entscheidung war. Intern macht
        <methodname>Zend_View::_run()</methodname> folgendes:
    </para>

    <programlisting language="php"><![CDATA[
protected function _run()
{
    include func_get_arg(0);
}
]]></programlisting>

    <para>
        Als solches, haben die View Skripte Zugriff auf das aktuelle Objekt
        (<varname>$this</varname>), <emphasis>und jede Methode oder jeden Member dieses
        Objekts</emphasis>. Da viele Operationen von Membern mit limitierter Sichtbarkeit abhängen,
        führt das zu einem Problem: Das View Skript können potentiell Aufrufe zu solchen Methoden
        tätigen, oder kritische Eigenschaften direkt ändern. Angenommen ein Skript überschreibt
        <varname>$_path</varname> oder <varname>$_file</varname> unabsichtlich -- jeder weitere
        Aufruf zu <methodname>render()</methodname> oder View Helfern würde fehlschlagen!
    </para>

    <para>
        Glücklicherweise hat <acronym>PHP</acronym> 5 eine Anwort auf das mit seiner Deklaration der
        Sichtbarkeit; Auf private Member kann nicht durch Objekte zugegriffen werden wenn eine
        bestehende Klasse erweitert wird. Das führt zum aktuellen Design: Da
        <classname>Zend_View</classname> <classname>Zend_View_Abstract</classname>
        <emphasis>erweitert</emphasis> sind View Skripte limitiert auf protected und public Methoden
        und Member von <classname>Zend_View_Abstract</classname> -- was effektiv die Aktionen
        beschränkt die durchgeführt werden können, und es erlaubt kritische Bereiche vor Missbrauch
        durch View Skripte zu schützen.
    </para>
</sect1>
<!--
vim:se ts=4 sw=4 et:
-->
