Previous Next

Darstellen der View

Wenn man den MVC Layer vom Zend Framework verwendet, sind die Chancen das man Zend_View verwendet recht hoch. Zend_View ist performant verglichen mit anderen View oder Templating Engines; da View Skripte in PHP geschrieben sind muß man weder den Overhead eines Kompilierungssystems zu PHP auf sich nehmen, noch muß man darauf achten das das kompilierte PHP nicht optimiert ist. Trotzdem zeigt Zend_View seine eigenen Probleme: Erweiterungen werden durch überladen (View Helfer) durchgeführt, und eine Anzahl von View Helfern, die dadurch Schlüsselfunktionalitäten bieten machen das auch, mit einem Verlust von Geschwindigkeit.

Wie kann ich die Auflösung von View Helfern schneller machen?

Die meisten Zend_View "Methoden" werden in Wirklichkeit durch Überladen des Helfersystems angeboten. Das bietet Zend_View wichtige Flexibilität; statt der Notwendigkeit Zend_View zu erweitern und alle Helfermethoden anzubieten die man in der eigenen Anwendung verwenden will, kann man eigene Helfermethoden in separaten Klassen definieren und Sie bei Bedarf konsumieren wie wenn es direkte Methoden von Zend_View wären. Das hält das View Objekt selbst relativ dünn, und stellt sicher das Objekte nur erstellt werden wenn Sie auch benötigt werden.

Intern verwendet Zend_View den PluginLoader um nach Helferklassen zu sehen. Das bedeutet das für jeden Helfer den man aufruft, Zend_View den Helfernamen zum PluginLoader übergeben muß, welcher dann den Klassennamen erkennen muß damit er instanziiert werden kann. Nachfolgende Aufrufe des Helfers sind viel schneller, da Zend_View eine interne Registry von geladenen Helfern behält, aber wenn man viele Helfer verwendet, werden die Aufrufe hinzuaddiert.

Die Frage ist also: Wie kann man die Auflösung der Helfer schneller machen?

Verwenden des PluginLoader Include-File Caches

Die einfachste, billigste Lösung ist die gleiche für die generelle PluginLoader Geschwindigkeit: Verwenden des PluginLoader Include-File Caches. Einzelberichte und aussagen haben gezeigt das diese Technik eine Geschwindigkeitssteigerung von 25-30% auf Systemen ohne Opcode Cache bringt, und eine 40-64% Steigerung auf Systemen mit Opcode Cache.

Erweitern von Zend_View um oft verwendet Helfermethoden anzubieten

Eine andere Lösung für jene die die Geschwindigkeit sogar noch mehr steigern wollen ist es Zend_Viewzu erweitern um manuell die Helfermethoden die man am meisten in seiner Anwendung verwendet hinzuzufügen. Solche Helfermethoden können einfach manuell die betreffenden Helferklassen instanziiert und auf Sie verwesen wird, oder indem die komplette Implementation des Helfers in die Methode eingefügt wird.

class My_View extends Zend_View
{
    /**
     * @var array Registry der verwendeten Helferklasse
     */
    protected $_localHelperObjects = array();

    /**
     * Proxy zum URL View Helfer
     *
     * @param  array $url  Options Optionen die an die Assemble Methode des
     *                     Route Objekts übergeben werden
     * @param  mixed $name Der Name der zu verwendenden Route. Wenn null wir
     *                     die aktuelle Route verwendet
     * @param  bool $reset Ob die Routenstandard mit den angegebenen resetiert
     *                     werden sollen oder nicht
     * @return string Url für das Link Href Attribut.
     */
    public function url(array $urlOptions = array(), $name = null,
        $reset = false, $encode = true
    ) {
        if (!array_key_exists('url', $this->_localHelperObjects)) {
            $this->_localHelperObjects['url'] = new Zend_View_Helper_Url();
            $this->_localHelperObjects['url']->setView($view);
        }
        $helper = $this->_localHelperObjects['url'];
        return $helper->url($urlOptions, $name, $reset, $encode);
    }

    /**
     * Eine Meldung ausgeben
     *
     * Direkte Implementierung.
     *
     * @param  string $string
     * @return string
     */
    public function message($string)
    {
        return "

" . $this->escape($message) . "

\n"; } }

Wie auch immer, diese Techik reduziert den Overhead des Helfersystems substanziell indem es den Aufruf vom PluginLoader komplett vermeidet, und entweder vom Autoloader profitiert, oder durch dessen Überbrückung.

Wie kann ich partielle View schneller machen?

Jene die Partielle sehr oft verwenden und die Ihre Anwendungen profilieren werden oft sofort feststellen das der partial() View Helfer viel des Overheads verwendet, durch die Notwendigkeit das View Objekt zu klonen. Ist es möglich das schneller zu machen?

Verwende partial() nur wenn es wirklich notwendig ist

Der partial() View Helfer akzeptiert drei Argumente:

  • $name: Den Namen des View Skripts das dargestellt werden soll

  • $module: Der Name des Moduls in dem das View Skript sitzt; oder, wenn kein drittes Argument angegeben wurde und es ein Array oder Objekt ist, wird es als $model Argument verwendet.

  • $model: Ein Array oder Objekt das dem Partial übergeben wird, und die reinen Daten repräsentiert die der View übergeben werden.

Die Power der Verwendung von partial() kommen vom zweiten und dritten Argument. Das $module Argument erlaubt es partial() temporär einen Skriptpfad für die angegebenen Module hinzuzufügen damit das partielle Viewskript es zu diesem Modul auflöst; das $model Argument erlaubt es Variablen explizit für die Verwendung in der partiellen View zu übergeben. Wenn man keines der Argumente übergibt, kann man stattdessen render() verwenden!

Grundsätzlich, solange man nicht Variablen an das Partial übergibt und einen reinen Variablenraum benötigt, oder ein Viewskript von einem anderen MVC Modul darstellt, gibt es keinen Grund den Overhead von partial() zu verwenden; stattdessen sollte man Zend_View's eingebaute render() Methode verwendet um das Viewskript darzustellen.

Wie kann ich Aufrufe zu action() vom View Helfers schneller machen?

Version 1.5.0 führte die action() des View Helfers ein, welche es erlaubt eine MVC Aktion abzuschicken und deren dargestellten Inhalt aufzufangen. Das biete einen wichtigen Schritt in die Prinzipien von DRY, und erlaubt die Wiederverwendung von Code. Trotzdem, wie jede die Ihre Anwendung profilieren schnell feststellen werden, ist es auch eine sehr teure Operation. Intern muß der action() Viewhelfer neue Anfrage und Antwort Objekte klonen, den Dispatcher aufrufen, den angefragten Controller und die Aktion aufrufen, usw.

Wie kann man das schneller machen?

Verwende den ActionStack wenn möglich

Zur selben Zeit die der action() View Helfer eingeführt, besteht der ActionStack auf einem Action Helfer und einem Front Controller Plugin. Zusammen erlauben Sie es zusätzliche Aktionen einzufügen die wärend des Dispatch Zyklus auf den Stack aufgerufen werden. Wenn man action() von eigenen Layout View Skripts aufruft, kann es sein das man stattdessen den ActionStack verwenden will, und die Views zu diskreten Antwortsegmenten darstellen will. Als Beispiel könnte man ein dispatchLoopStartup() Plugin wie das folgende schreiben um eine Login Formularbox bei jeder Seite hinzuzufügen:

class LoginPlugin extends Zend_Controller_Plugin_Abstract
{
    protected $_stack;

    public function dispatchLoopStartup(
        Zend_Controller_Request_Abstract $request
    ) {
        $stack = $this->getStack();
        $loginRequest = new Zend_Controller_Request_Simple();
        $loginRequest->setControllerName('user')
                     ->setActionName('index')
                     ->setParam('responseSegment', 'login');
        $stack->pushStack($loginRequest);
    }

    public function getStack()
    {
        if (null === $this->_stack) {
            $front = Zend_Controller_Front::getInstance();
            if (!$front->hasPlugin('Zend_Controller_Plugin_ActionStack')) {
                $stack = new Zend_Controller_Plugin_ActionStack();
                $front->registerPlugin($stack);
            } else {
                $stack = $front->getPlugin('ActionStack')
            }
            $this->_stack = $stack;
        }
        return $this->_stack;
    }
}

Die UserController::indexAction() Methode könnte dann den responseSegment Parameter verwenden um anzuzeigen welches Antwortsegment darzustellen ist. Im Layoutskript, würde man dann einfach das Antwortsegment darstellen:

layout()->login ?>

Wärend der ActionStack trotzdem noch einen Dispatch Zyklus benötigt, ist das trotzdem immer noch billiger als der action() View Helfer da er Objekte nicht klonen und den internen Status resetieren muß. Zustzlich stellt es sicher das alle Pre/Post Dispatch Plugins aufgerufen werden, was von spezieller Wichtigkeit ist wenn man Frontcontroller Plugins für die Behandlung von ACLs in speziellen Aktionen verwendet.

Helfer bevorzugen die das Modell vor action() abfragen

In den meisten Fällen ist die Verwendung von action() einfach nur Overkill. Wenn man die meiste Businesslogik in eigenen Modellen verschachtelt hat das Modell einfach abfragt und die Ergebnisse an das View Skript übergibt, ist es typischerweise schneller und sauberer einfach einen View Helfer zu schreiben der das Modell holt, es abfragt und mit der Information irgendwas macht.

Nehmen wir als Beispiel die folgende Controller Action und das View Skript an:

class BugController extends Zend_Controller_Action
{
    public function listAction()
    {
        $model = new Bug();
        $this->view->bugs = $model->fetchActive();
    }
}

// bug/list.phtml:
echo "
    \n"; foreach ($this->bugs as $bug) { printf("
  • %s: %s
  • \n", $this->escape($bug->id), $this->escape($bug->summary)); } echo "
\n";

Mit Verwendung von action(), würde man es einfach wie folgt einfügen:

action('list', 'bug') ?>

Das könnte zu einem View helfer geändert werden die wie folgt aussieht:

class My_View_Helper_BugList extends Zend_View_Helper_Abstract
{
    public function bugList()
    {
        $model = new Bug();
        $html  = "
    \n"; foreach ($model->fetchActive() as $bug) { $html .= sprintf("
  • %s: %s
  • \n", $this->view->escape($bug->id), $this->view->escape($bug->summary) ); } $html .= "
\n"; return $html; } }

Der Helfer würde dann wie folgt aufgerufen werden:

bugList() ?>

Das hat zwei Vorteile: Es übernimmt nicht länger den Overhead vom action() View Helfer, und präsentiert eine bessere und semantisch verständlichere API.

Previous Next
Introduction to Zend Framework
Übersicht
Installation
Zend_Acl
Einführung
Verfeinern der Zugriffskontrolle
Fortgeschrittene Verwendung
Zend_Amf
Einführung
Zend_Amf_Server
Zend_Application
Einführung
Zend_Application Quick Start
Theorie der Funktionsweise
Beispiele
Kern Funktionalität
Vorhandene Ressource Plugins
Zend_Auth
Einführung
Datenbanktabellen Authentifizierung
Digest Authentication
HTTP Authentication Adapter
LDAP Authentifizierung
Open ID Authentifikation
Zend_Cache
Einführung
Die Theorie des Cachens
Zend_Cache Frontends
Zend_Cache Backends
Zend_Captcha
Einführung
Captcha Anwendung
CAPTCHA Adapter
Zend_CodeGenerator
Einführung
Zend_CodeGenerator Beispiele
Zend_CodeGenerator Referenz
Zend_Config
Einleitung
Theory of Operation
Zend_Config_Ini
Zend_Config_Xml
Zend_Config_Writer
Zend_Config_Writer
Zend_Console_Getopt
Einführung
Definieren von Getopt Regeln
Holen von Optionen und Argumenten
Konfigurieren von Zend_Console_Getopt
Zend_Controller
Zend_Controller Schnellstart
Zend_Controller Grundlagen
Der Front Controller
Das Request Objekt
Der Standard Router
Der Dispatcher
Action Kontroller
Action Helfer
Das Response Objekt
Plugins
Eine konventionelle modulare Verzeichnis Struktur verwenden
MVC Ausnahmen
Migration von vorhergehenden Versionen
Zend_Currency
Einführung in Zend_Currency
Arbeiten mit Währungen
Migration von vorhergehenden Versionen
Zend_Date
Einführung
Theorie der Arbeitsweise
Basis Methoden
Zend_Date API Übersicht
Erstellen von Datumswerten
Konstanten für generelle Datums Funktionen
Funktionierende Beispiele
Zend_Db
Zend_Db_Adapter
Zend_Db_Statement
Zend_Db_Profiler
Zend_Db_Select
Zend_Db_Table
Zend_Db_Table_Row
Zend_Db_Table_Rowset
Zend_Db_Table Relationships
Zend_Debug
Variablen ausgeben
Zend_Dojo
Einführung
Zend_Dojo_Data: dojo.data Envelopes
Dojo View Helfer
Formular Elemente und Dekoratore für Dojo
Zend_Dom
Einführung
Zend_Dom_Query
Zend_Exception
Verwenden von Ausnahmen
Zend_Feed
Einführung
Feeds importieren
Feeds von Websites abrufen
Einen RSS Feed konsumieren
Einen Atom Feed konsumieren
Einen einzelnen Atom Eintrag konsumieren
Verändern der Feed- und Eintragsstruktur
Eigene Klassen für Feeds und Einträge
Zend_File
Zend_File_Transfer
Prüfungen für Zend_File_Transfer
Filter für Zend_File_Transfer
Migration von vorhergehenden Versionen
Zend_Filter
Einführung
Standard Filter Klassen
Filter Ketten
Filter schreiben
Zend_Filter_Input
Zend_Filter_Inflector
Zend_Form
Zend_Form
Schnellstart mit Zend_Form
Erstellen von Form Elementen mit Hilfe von Zend_Form_Element
Erstellen von Form durch Verwendung von Zend_Form
Erstellen von eigenem Form Markup durch Zend_Form_Decorator
Standard Form Elemente die mit dem With Zend Framework ausgeliefert werden
Standard Formular Dekoratoren die mit dem Zend Framework ausgeliefert werden
Internationalisierung von Zend_Form
Fortgeschrittene Verwendung von Zend_Form
Zend_Gdata
Einführung
Authentifizierung mit AuthSub
Die Buchsuche Daten API verwenden
Authentifizieren mit ClientLogin
Google Kalender verwenden
Verwenden der Google Dokumente Listen Daten API
Verwenden von Google Health
Google Tabellenkalkulation verwenden
Google Apps Provisionierung verwenden
Google Base verwenden
Picasa Web Alben verwenden
Verwenden der YouTube Daten API
Gdata Ausnahmen auffangen
Zend_Http
Einführung
Zend_Http_Client - Fortgeschrittende Nutzung
Zend_Http_Client - Verbindungsadapter
Zend_Http_Cookie und Zend_Http_CookieJar
Zend_Http_Response
Zend_InfoCard
Einführung
Zend_Json
Einführung
Grundlegende Verwendung
Fortgeschrittene Verwendung von Zend_Json
XML zu JSON Konvertierung
Zend_Json_Server - JSON-RPC server
Zend_Layout
Einführung
Zend_Layout Schnellstart
Zend_Layout Konfigurations Optionen
Erweiterte Verwendung von Zend_Layout
Zend_Ldap
Einleitung
Zend_Loader
Dynamisches Laden von Dateien und Klassen
Der Autoloader
Ressource Autoloader
Plugins laden
Zend_Locale
Einführung
Zend_Locale verwenden
Normalisierung und Lokalisierung
Arbeiten mit Daten und Zeiten
Unterstützte Gebietsschemata
Migrieren von vorhergehenden Versionen
Zend_Log
Übersicht
Writer
Formatter
Filter
Zend_Mail
Einführung
Versand über SMTP
Versand von mehreren E-Mails über eine SMTP Verbindung
Verwendung von unterschiedlichen Versandwegen
HTML E-Mail
Anhänge
Empfänger hinzufügen
Die MIME Abgrenzung kontrollieren
Zusätzliche Kopfzeilen
Zeichensätze
Kodierung
SMTP Authentifizierung
SMTP Übertragungen sichern
Lesen von Mail Nachrichten
Zend_Measure
Einführung
Erstellung einer Maßeinheit
Ausgabe von Maßeinheiten
Manipulation von Maßeinheiten
Arten von Maßeinheiten
Zend_Memory
Übersicht
Memory Manager
Memory Objekte
Zend_Mime
Zend_Mime
Zend_Mime_Message
Zend_Mime_Part
Zend_Navigation
Einführung
Seiten
Container
Zend_OpenId
Einführung
Zend_OpenId_Consumer Grundlagen
Zend_OpenId_Provider
Zend_Paginator
Einführung
Verwendung
Konfiguration
Advanced usage
Zend_Pdf
Einführung
Erstellen und Laden von PDF Dokumenten
Änderungen an PDF Dokumenten speichern
Arbeiten mit Seiten
Zeichnen
Dokument Informationen und Metadaten
Anwendungsbeispiel für die Zend_Pdf Komponente
Zend_ProgressBar
Zend_ProgressBar
Zend_Reflection
Einführung
Zend_Reflection Beispiele
Zend_Reflection Referenz
Zend_Registry
Die Registry verwenden
Zend_Rest
Einführung
Zend_Rest_Client
Zend_Rest_Server
Zend_Search_Lucene
Überblick
Indexerstellung
Einen Index durchsuchen
Abfragesprache
Abfrage Erzeugungs API
Zeichensätze
Erweiterbarkeit
Zusammenarbeit Mit Java Lucene
Erweitert
Die besten Anwendungen
Zend_Server
Einführung
Zend_Server_Reflection
Zend_Service
Einführung
Zend_Service_Akismet
Zend_Service_Amazon
Zend_Service_Amazon_Ec2
Zend_Service_Amazon_Ec2: Instanzen
Zend_Service_Amazon_Ec2: Windows Instances
Zend_Service_Amazon_Ec2: Reserved Instances
Zend_Service_Amazon_Ec2: CloudWatch Monitoring
Zend_Service_Amazon_Ec2: Amazon Maschinen Images (AMI)
Zend_Service_Amazon_Ec2: Elastischer Block Speicher (EBS)
Zend_Service_Amazon_Ec2: Elastische IP Adressen
Zend_Service_Amazon_Ec2: Schlüsselpaare
Zend_Service_Amazon_Ec2: Regionen und Availability Zones
Zend_Service_Amazon_Ec2: Sicherheitsgruppen
Zend_Service_Amazon_S3
Zend_Service_Audioscrobbler
Zend_Service_Delicious
Zend_Service_Flickr
Zend_Service_Nirvanix
Zend_Service_ReCaptcha
Zend_Service_Simpy
Einführung
Zend_Service_StrikeIron
Zend_Service_StrikeIron: Mitgelieferte Services
Zend_Service_StrikeIron: Erweiterte Verwendung
Zend_Service_Technorati
Zend_Service_Twitter
Zend_Service_Yahoo
Zend_Session
Einführung
Grundsätzliche Verwendung
Fortgeschrittene Benutzung
Globales Session Management
Zend_Session_SaveHandler_DbTable
Zend_Soap
Zend_Soap_Server
Zend_Soap_Client
WSDL Zugriffsmethoden
AutoDiscovery
Zend_Tag
Einführung
Zend_Tag_Cloud
Zend_Test
Einführung
Zend_Test_PHPUnit
Zend_Text
Zend_Text_Figlet
Zend_Text_Table
Zend_TimeSync
Einführung
Arbeiten mit Zend_TimeSync
Zend_Tool_Framework
Einführung
Verwenden des CLI Tools
Architecture
Erstellen von Providern für die Verwendung mit Zend_Tool_Framework
Mitgelieferte System Provider
Zend_Tool_Project
Zend_Tool_Project Einführung
Ein Projekt erstellen
Project Provider für Zend Tool
Zend_Translate
Einführung
Adapter für Zend_Translate
Benutzen von Übersetzungs Adaptoren
Migration von vorhergehenden Versionen
Zend_Uri
Zend_Uri
Zend_Validate
Einführung
Standard Prüfklassen
Kettenprüfungen
Schreiben von Prüfern
Prüfungsmeldungen
Zend_Version
Die Version des Zend Frameworks erhalten
Zend_View
Einführung
Controller Skripte
View Scripte
View Helfer
Zend_View_Abstract
Migration von vorhergehenden Versionen
Zend_Wildfire
Zend_Wildfire
Zend_XmlRpc
Einführung
Zend_XmlRpc_Client
Zend_XmlRpc_Server
Zend Framework Voraussetzungen
Einführung
Zend Framework Coding Standard für PHP
Übersicht
PHP Dateiformatierung
Namens Konventionen
Code Stil
Zend Framework Performance Guide
Einführung
Laden von Klassen
Zend_Db Performance
Internationalisierung (I18n) und Lokalisierung (L10n)
Darstellen der View
Urheberrecht Informationen