1. 14.09.2010

    Brauchbarer Ersatz für Zend_View_Helper_Navigation_Menu

    Nicht nur am Klassennamen bricht man sich einen ab, auch bei der Verwendung von Zend_View_Helper_Navigation_Menu stellt man relativ schnell fest, dass der View-Helper zum erzeugen von Menüs aus Zend_Navigation nur eingeschränkt brauchbar ist.

    Ein Beispiel aus der Praxis. Nehmen wir folgende Menüstruktur an:

    • Home
    • Inhalt
      • Seite 1
      • Seite 2 (isActive)
    • anderer Inhalt
      • Seite 3
        • Seite 4
        • Seite 5
      • Seite 6
    • Login

    Nehmen wir an, die aktuelle Seite die angezeigt wird ist “Seite 2” und diese ist in Zend_Navigation auch als solche markiert. Mit dem vorhandenen View-Helper kann man das Menü jetzt nur wie folgt rendern lassen:

    Vollständig mit allen Untermenüs:

    • Home
    • Inhalt
      • Seite 1
      • Seite 2 (isActive)
    • anderer Inhalt
      • Seite 3
        • Seite 4
        • Seite 5
      • Seite 6
    • Login

    Auf eine der Ebenen beschränken (Depth):

    • Home
    • Inhalt
    • anderer Inhalt
    • Login

    Oder nur den aktiven Branch:

    • Inhalt
      • Seite 1
      • Seite 2 (isActive)

    Was nicht geht, aber sicherlich der gängigste Ansatz eines Menüs ist, nämlich nur den aktiven Branch ausgeklappt anzeigen zu lassen, geht nicht. Also zum Beispiel folgendes:

    • Home
    • Inhalt
      • Seite 1
      • Seite 2 (isActive)
    • anderer Inhalt
    • Login

    Was auch üblich ist, dass wenn ein Menüpunkt, der Untermenüs besitzt, aktiv ist, dieses Untermenü nur in der nächsten Ebene anzuzeigen. Beispiel:

    • Home
    • Inhalt
    • anderer Inhalt (isActive)
      • Seite 3
      • Seite 6
    • Login

    Wer einen brauchbaren View-Helper für die letzten beiden Fälle benötigt, ist aktuell bei Zend aufgeschmissen. Was für mich nicht verständlich ist, ist die Tatsache, dass bereits seit Juni 2009 ein passender Patch von Patrice De Saint Steban zur Verfügung steht und bis dato nicht den Weg in das offizielle Release gefunden hat. Dabei ist seine Lösung so smart und einfach, dass es keine Hürde geben sollte.

    Ich habe den Patch in mein persönliches Framework übernommen. Nicht als Patch der eigentlichen Klasse im Zend Framework, sondern als eigene Klasse, die ich dann als View-Helper in der Bootstrap.php registriere:

    	protected function _initNavigation()
	{
		$this->bootstrap('view');
		$this->bootstrap('acl');
		$acl = $this->getResource('acl');
		$view = $this->getResource('view');
		$config = new Zend_Config_Ini(APPLICATION_PATH.DIRECTORY_SEPARATOR.'configs'.DIRECTORY_SEPARATOR.'navigation.ini');
		$navigation = new Zend_Navigation($config);
		$helper = new Paaliaq_View_Helper_Navigation_Menu();
		$view->registerHelper($helper, 'menu');
		$view->menu($navigation);
		$view->menu()->setAcl($acl);
		return $navigation;
	}

    Zu beachten ist, dass der neue View-Helper nicht auf navigation() sondern auf menu() hört. Und schon kann man mit Zend_Navigation und dem eigenen View-Helper auch brauchbare Menüs zaubern.

    2. Kommentare
  2. 31.08.2010

    Zend Framework mit Smarty verbinden

    Der Entwickler Moo hat in seinem Blog einen interessanten Artikel über den Einsatz der weit verbreiteten und sehr beliebten Template-Engine Smarty in Projekten mit dem Zend Framework verfasst.

    Im Unterschied zu vielen anderen Artikeln die es dazu schon gibt, ist dieser brandaktuell und berücksichtigt insbesondere die Neuerungen rund um das Zend_Layouts ab der Version 1.10 des PHP Frameworks. Der Artikel ist ein sehr guter Einstiegspunkt wenn man plant beide Welten in eigenen Projekten miteinander zu vereinen.

    Aus meiner Sicht gibt es leider noch zwei Punkte die nicht so schön sind und einer 100% Verschmelzung noch im Wege stehen. Dazu gehört, dass die Templates weiterhin *.phtml als Suffix haben, statt den von Smarty üblichen *.tpl. Das ließe sich zwar einfach mit der Zeile

    $viewRender->setViewSuffix('tpl');

    in der Init-Funktion des Views in der Bootstrap-Klasse ändern, aber wenn man das Zend_Tool “zf” verwendet um Controller und Actions automatisch anzulegen, werden die dazugehörigen View-Skripte automatisch als *.phtml erzeugt. Die könnte man zwar danach umbenennen oder auch den Provider der Funktion von Zend_Tool anpassen, aber das ist viel Aufwand für so einen “Schönheitsfehler”. Ich bevorzuge daher meiner IDE mitzuteilen, dass *.phtml Smarty-Templates sind, damit das Syntax-Highlighting funktioniert. Mehr brauche ich nicht.

    Der andere Schönheitsfehler ist der von Moo vorgeschlagene Workaround für die gleichen Scopes von Smarty und Zend_View bzw. Zend_Layout:

    $this->assign('_view', $this);
$this->assign('_layout', $this->layout());

    Dieser Workaround ist leider unumgänglich, denn sowohl Smarty als auch Zend_View beanspruchen das $this in den Templates für sich. Das ist echt gewöhnungsbedürftig.

    Wenn man statt der noch aktuellen Version 2.6.x die neue Version 3.0 (immer noch RC) von Smarty einsetzen möchte, dann sollte man den Hinweis in den Kommentaren berücksichtigen, dass die Funktion get_template_vars($key) deprecated ist und durch die Funktion getTemplateVars($key) in der View-Klasse für Smarty ersetzt werden muss.

    3. Kommentare

« Previous Next »