Archiv für die 'Fragestunde' Kategorie

Zend Framework FAQ: Wo platziere ich am besten meine Validatoren und Filter, im Controller, im Formular oder im Model?

Samstag, 09.01.2010

Bei der zweiten Abstimmung für die Zend Framework Fragestunde, wurde diese Frage mit 29% der Stimmen auf Platz 1 gewählt: Wo platziere ich am besten meine Validatoren und Filter, im Controller, im Formular oder im Model? Setze ich dabei Zend_Filter_Input ein? Es hat ein wenig gedauert (mehr als zwei Monate), bis ich nun endlich dazu gekommen bin, mich dieser Frage anzunehmen. Dies hatte mehrere Gründe, denn ich war sowohl beruflich als auch privat sehr eingespannt. Bin ich eigentlich immer noch, aber heute habe ich mir die Zeit genommen. Sonst wird die Fragestunde auch eher langweilig und wieder schnell vergessen.

Ein Grund, weshalb die Antwort so lange auf sich warten liess, war auch, dass diese Frage auf den ersten Blick gar nicht so leicht zu beantworten ist. Der Frage ist schon zu entnehmen, dass es viele Möglichkeiten gibt. Werden die Validatoren und Filter im Controller, im Formular oder im Model platziert? Verwendet man lieber Zend_Form oder Zend_Filter_Input? Ich werde hier nun zwei Lösungswege vorstellen, möchte aber auch darauf hinweisen, dass es weitere sinnvolle und gute Lösungen gibt. Und eigentlich ist die Frage auch etwas ungenau gestellt. Denn das Platzieren der Validatoren und Filter ist relativ klar. Unklar ist eher, wann und wo das Filtern und Validieren ausgeführt wird. Doch dazu gleich mehr.

Ansatz 1: Zend_Form zum Filtern und Validieren verwenden

Es ist nahe liegend, für das Filtern und Validieren von Eingabedaten Zend_Form zu verwenden. Diese Komponente bietet bereits alles, was man braucht. Es ist recht einfach, einem Formular beliebige Filter und Validatoren zuzuordnen. Dies ist auch meiner Meinung nach gut im Referenzhandbuch für Zend_Form erläutert, so dass ich dies hier nicht wiederholen möchte. Auch im Quickstart findet sich ein Beispiel. Komplizierter ist aber die Frage, wo in einer Anwendung die isValid() Methode einer Zend_Form Instanz aufgerufen wird.

Als erstes bietet sich der Einsatz im Action-Controller an. Dies ist auch nahe liegend, da der Controller unter anderem auch für die Verarbeitung und Weitergabe der Eingabedaten zuständig ist. Ein Model oder gar eine Formularinstanz sollte nie direkt auf die Daten zugreifen, die über den Request des Benutzers eingehen. In der Regel könnte solch ein Abfrage mehr oder minder wie im folgenden Beispiel aussehen. Es wird eine Instanz des Formulars erstellt, dann wird geprüft, ob das Formular gültig ist. Falls ja, wird erst die Instanz des Models erstellt und dann kann wie in diesem Beispiel ein neues Passwort für einen Benutzer erstellt werden.

PHP:
  1. function passwordAction()
  2. {
  3.   // Formular für neues Benutzerpasswort
  4.   $form = new App_Form_UserPassword();
  5.  
  6.   // prüfen ob Formular mit Button versandt wurde
  7.   if ($this->getRequest()->isPost() && !is_null($this->getRequest()->getPost('submit_user_password')))
  8.   {
  9.     // prüfen ob Eingaben gültig sind
  10.     if ($form->isValid($this->getRequest()->getPost()))
  11.     {
  12.       // Model Instanz erstellen
  13.       $user = new App_Model_Users();
  14.  
  15.       // Neues Passwort generieren
  16.       $user->generatePassword($form->getValue('user_email'));
  17.  
  18.       // umleiten auf Bestätigung
  19.       return $this->_redirect($this->getHelper('url')->url(array('action' => 'password-sent', 'id' => $user->getId())));
  20.     }
  21.  
  22.     // Daten sind ungültig
  23.     else
  24.     {
  25.       // Fehlermeldung festlegen
  26.       $form->setDescription('message_user_password_error');
  27.     }
  28.   }
  29.  
  30.   // Formular an View übergeben
  31.   $this->view->passwordForm = $form;
  32. }

Diese Verwendung ist nahe liegend und sieht auf den ersten Blick auch solide aus. Und es funktioniert auch soweit ganz gut. Das Problem ist nur, was man macht, wenn ein Formular z.B. an verschiedenen Stellen einer Anwendung zum Einsatz kommt. Dann muss in der jeweiligen Aktionsmethode des Action-Controller diese Prüfung laufend wiederholt wird. Ich denke da an den Ansatz der "thin controller and fat models" und möchte die Aktionsmethoden so einfach wie möglich halten. Deshalb möchte ich die eigentliche Prüfung der Daten lieber aus dem Controller heraus in das Model verlagern.

Dies hat auch den Vorteil, dass die Prüfung der Daten auch gewährleistet ist, falls ein Model einen neuen Datensatz anlegen soll, der nicht über ein Web-Formular in der Anwendung landet (z.B. beim Importieren von Daten aus einer externen Quelle). Und es macht keinen Sinn, die Prüfung der Eingabedaten redundant im Controller und im Model zu implementieren.

Zuerst schauen wir uns den Ausschnitt aus dem Model an. Es erstellt eine Instanz des Formulars und überprüft die Korrektheit der Daten, wenn das Formular abgeschickt worden ist. Wenn die Eingaben korrekt ware, wird ein neues Passwort erstellt und gespeichert, danach wird eine Mail mit dem Passwort versandt. Wenn dies nicht geklappt hat oder das Formular nicht versandt wurde, wird die Instanz des Formulars zurück gegeben.

PHP:
  1. class App_Model_Users
  2. {
  3.     public function generatePassword(array $data = array())
  4.     {
  5.         // Formular für neues Benutzerpasswort
  6.         $form = new App_Form_UserPassword();
  7.        
  8.         // prüfen ob Formular mit Button versandt wurde
  9.         if (isset($data['submit_user_password'])) {
  10.             // prüfen ob Eingaben gültig sind
  11.             if ($form->isValid($data)) {
  12.                 // Daten übernehmen, Passwort erstellen und speichern
  13.                 $this->setProperties($form->getValues());
  14.                 $this->setPassword(App_Model_Users::generatePassword());
  15.                 $this->save();
  16.                
  17.                 // Mail mit neuem Passwort aufbauen und versenden
  18.                 $mail = new Zend_Mail();
  19.                 $mail->setFrom('webmaster@mydomain.de');
  20.                 $mail->addTo($this->getEmail());
  21.                 $mail->setSubject('Neues Passwort');
  22.                 $mail->setBodyText('Passwort: ' . $this->getPassword());
  23.                 $mail->send();
  24.                
  25.                 // Registrierung erfolgreich
  26.                 return true;
  27.            
  28.             } else {
  29.                 // Fehlermeldung festlegen
  30.                 $form->setDescription('message_user_password_error');
  31.             }
  32.         }
  33.        
  34.         // Formularobjekt zurück geben
  35.         return $form;
  36.     }
  37. }

Als nächstes schauen wir uns den Action-Controller an. Hier wird nun nicht mehr die Instanz des Formulars, sondern die des Models erstellt. Es gibt eine spezielle Methode für das Erstellen eines neuen Passworts. Diese gibt entweder ein true oder eine Formularinstanz zurück.

PHP:
  1. class UserController extends Zend_Controller_Action   
  2. {
  3.     public function passwordAction()
  4.     {
  5.         // Model für Benutzer instanzieren
  6.         $user = new App_Model_Users();
  7.        
  8.         // Passwort erstellen
  9.         $form = $user->generatePassword($this->getRequest()->getPost());
  10.        
  11.         // Prüfen auf Redirect
  12.         if (true === $form) {
  13.             // umleiten auf Bestätigung
  14.             return $this->_redirect($this->getHelper('url')->url(array('action' => 'password-sent', 'id' => $user->getId())));
  15.         }
  16.        
  17.         // Übergebe Formular an den View
  18.         $this->view->passwordForm = $form;
  19.     }
  20. }

Wir verwenden nun also das Zend_Form Objekt innerhalb unseres Models und der Action-Controller muss sich um fast nichts mehr kümmern. Nur die Weiterleitung und die Übergabe an den View sind noch für ihn zu erledigen.

Ansatz 2: Zend_Filter_Input zum Filtern und Validieren verwenden

Verzichtet man aus welchen Gründen auch immer auf den Einsatz von Zend_Form, kann man das Filtern und Validieren alternativ auch von Zend_Filter_Input erledigen lassen. Die Funktionsweise ist im Referenzhandbuch erklärt, so dass ich mir die Einführung von Zend_Filter_Input an dieser Stelle sparen möchte.

Der Einsatz innerhalb eines Models ist aber recht schnell dargestellt. Die Unterschiede zum Einsatz von Zend_Form sind marginal.

PHP:
  1. class App_Model_Users
  2. {
  3.     public function generatePassword(array $data = array())
  4.     {
  5.         // Zend_Filter_Input Instanz
  6.         $input = new App_Filter_UserPassword();
  7.        
  8.         // prüfen ob Formular mit Button versandt wurde
  9.         if (isset($data['submit_user_password'])) {
  10.             // prüfen ob Eingaben gültig sind
  11.             if ($input->isValid($data)) {
  12.                 // Daten übernehmen, Passwort erstellen und speichern
  13.                 $this->setProperties($input->getEscaped());
  14.                 $this->setPassword(App_Model_Users::generatePassword());
  15.                 $this->save();
  16.                
  17.                 // Mail mit neuem Passwort aufbauen und versenden
  18.                 $mail = new Zend_Mail();
  19.                 $mail->setFrom('webmaster@mydomain.de');
  20.                 $mail->addTo($this->getEmail());
  21.                 $mail->setSubject('Neues Passwort');
  22.                 $mail->setBodyText('Passwort: ' . $this->getPassword());
  23.                 $mail->send();
  24.                
  25.                 // Registrierung erfolgreich
  26.                 return true;
  27.         }
  28.        
  29.         // Nicht erfolgreich
  30.         return false;
  31.     }
  32. }

Da ich selber Zend_Form sehr gerne und viel einsetze, habe ich Zend_Filter_Input noch nicht so häufig in der Praxis eingesetzt. Aber es ist durchaus möglich, wie das Beispiel zeigt.

Fazit

Das Filtern und Validieren von Eingabedaten ist im Model meistens am besten aufgehoben. Ob man nun Zend_Form oder Zend_Filter_Input einsetzt, bleibt einem selbst überlassen. Beides ist möglich.

Wenn es Fragen gibt oder ihr dies oder jenes völlig anders macht, stehen dafür nun die Kommentare bereit. Ich freue mich auf euer Feedback!

Tweet this via redir.ec

2. Zend Framework Fragestunde: Abstimmung

Donnerstag, 05.11.2009

Seit Montag konnten wieder neue Fragen für die 2. Zend Framework Fragestunde abgegegeben werden. In den Kommentaren sind zwar dieses Mal keine neuen Fragen eingegangen, aber über Twitter als PM und per E-Mail sind insgesamt 3 neue Fragen eingetroffen. Davon habe ich 2 ausgewählt. Und aus den Fragen der letzten Abstimmung habe ich auch drei unbeantwortete genommen. Es folgen also nun die 5 Fragen zum Zend Framework:

  1. Ist es legitim oder nicht, aus einem View-Script auf ein Model zuzugreifen, um Daten geliefert zu bekommen?
  2. Wie erstelle ich am besten ein CMS, welches in der Mitte immer den Inhalt meines Moduls anzeigen, links und rechts sollen aber "Kästchen sein", z.B. wie in diesem Blog hier.
  3. Wie testet man die “application/configs/application.ini” (ZF1.9.3) mit PHPUnit? Wie würde der Test für “public/index.php” aussehen?
  4. Wo platziere ich am besten meine Validatoren und Filter, im Controller, im Formular oder im Model? Setze ich dabei Zend_Filter_Input ein?
  5. Wie erstelle und nutze ich ein eigenes Ressource Plugin, z.B. für den Einsatz von Zend_Log?

Welche Frage soll in der 2. Zend Framework Fragestunde beantwortet werden?

  • Frage 1 (9%, 9 Stimmen)
  • Frage 2 (27%, 27 Stimmen)
  • Frage 3 (26%, 26 Stimmen)
  • Frage 4 (29%, 29 Stimmen)
  • Frage 5 (9%, 10 Stimmen)

Anzahl der Abstimmer: 101

Und zum Abschluss wieder der Hinweis: bitte reißt euch zusammen und versucht, die Abstimmung nicht zu manipulieren. So etwas machen nämlich nur Warmduscher. Beim letzten Mal gab es einige Warmduscher... ;-)

Tweet this via redir.ec

2. Zend Framework Fragestunde: Fragensammlung

Montag, 02.11.2009

Die 1. Zend Framework Fragestunde ist mit ihrer Fragensammlung, der Abstimmung und der Antwort bereits Geschichte. Doch wir wollen hier keine Müdigkeit vorschützen und gleich mit der 2. Zend Framework Fragestunde weiter machen. Auch dieses Mal sammeln wir zuerst die Fragen, machen dann eine Abstimmung und dann darf ich die Frage mit den meisten Stimmen beantworten. Vom letzten Mal sind noch folgende Fragen offen:

  • Ist es legitim oder nicht, aus einem View-Script auf ein Model zuzugreifen, um Daten geliefert zu bekommen?
  • Wie erstelle ich am besten ein CMS, welches in der Mitte immer den Inhalt meines Moduls anzeigen, links und rechts sollen aber "Kästchen sein", z.B. wie in diesem Blog hier.
  • Welche Vorteile und Nachteile besitzt die modulare Verzeichnisstruktur im Vergleich zum konventionellen Aufbau?
  • Wie testet man die “application/configs/application.ini” (ZF1.9.3) mit PHPUnit? Wie würde der Test für “public/index.php” aussehen?

Diese Fragen können wir gerne wieder zur Abstimmung stellen. Ihr könnt aber natürlich auch wieder neue Fragen stellen. Vielleicht haben sich aus der Antwort zur letzten Fragestunde auch wieder neue Fragen ergeben? Immer her damit. Und da leider nichts ohne Regeln auskommt, auch hier wieder selbige. Die alten Fragestunde-Hasen kennen dies bereits:

  • Bitte erwartet keine vollständig aus programmierten Lösungen für eure Fragen. Das ließe sich in meiner Freizeit kaum bewerkstelligen. Wenn ich selber einen passenden Code-Schnipsel parat habe, werde ich den aber natürlich nicht vorenthalten. Bitte erwartet auch bei sehr konkreten Fragen zu ganz speziellen Problemen keine Wunderlösungen.
  • Eine Frage sollte auch nicht aus Hunderten oder gar Tausenden Zeilen Programmcode bestehen, der nicht funktioniert, so dass ich den Fehler für euch finden soll. Da sind die Mailinglisten oder das Zend Framework Forum der bessere Ort, um fundierte Antworten zu erhalten.
  • Für die Abstimmung werde ich maximal 5 bis 6 Fragen auswählen, damit die Abstimmung auch etwas bringt. Fragen, die unbeantwortet bleiben oder nicht zur Abstimmung gestellt wurden, können bei der nächsten Fragestunde gerne wiederholt werden. Wenn bei der Abstimmung zu den Fragen offensichtlich manipuliert wird, fliegt diese raus bis zum nächsten Mal. Danach beginnt der Zyklus wieder von Vorne.
  • Gerne können auch Gastautoren eine Frage beantworten, wenn diese ihrem Spezialgebiet entspricht.
  • Eine Frage darf übrigens nicht länger als 200 Zeichen lang sein. Warum? Weil das Abstimmungstool nur 200 Zeichen pro Abstimmungspunkt zulässt. Wenn wir aber im Laufe der Fragestunde merken, dass 200 Zeichen doch wenig sind, werde ich mir etwas überlegen.

Und nun kann es wieder los gehen. Stellt eure Fragen zum Zend Framework, die ihr immer schon mal stellen wollt. Die Fragensammlung werde ich Mittwoch, den 4.11. abends offen halten.

Tweet this via redir.ec

Zend Framework FAQ: Wie setze ich eine ACL für eine Modul basierte Applikation um?

Montag, 26.10.2009

Bei der ersten Abstimmung für die Zend Framework Fragestunde, wurde diese Frage mit 37% der Stimmen auf Platz 1 gewählt: Wie setze ich eine ACL für eine Modul basierte Applikation um?

Hierfür müssen wir als erstes die Grundlage schaffen und festlegen, was eigentlich mit einer Modul basierten Applikation gemeint ist. Das Zend Framework bietet schon seit einen frühen Anfängen die Möglichkeit, eine Applikation in Module aufzuteilen. In einem Modul können somit Action-Controller, View-Skripte, Models, Formulare und mehr gekapselt werden. Die Klassen dieser Module bekommen einen eigenen vorangestellten Namensraum, damit es nicht zu Namenskonflikten kommen kann. Eine Zend Framework Applikation könnte somit aus den Modulen Gästebuch, Forum und CMS (für Ausgabe von Textbeiträgen) bestehen. Zusätzlich zu diesen Modulen gibt es in der Regel immer ein Default-Modul, dass sich unter anderem um die Auslieferung der Homepage kümmert. Zusammenfassend werden wir also mit den folgenden Module arbeiten:

  • default
  • guestbook
  • forum
  • cms

Um mit Zend_Acl eine ACL (Access Control List) umsetzen zu können, benötigen wir noch die Benutzerrollen. Wir verwenden an dieser Stelle die drei Benutzerrollen admin, editor und guest und gehen davon aus, dass in allen Modulen die selben Benutzerrollen verwendet werden sollen. Den Aspekt der Wiederverwendbarkeit der Module lasse ich an dieser Stelle bewusst unberücksichtigt. Denn dies würde das Ganze nur noch komplizierter machen.

Als nächstes müssen wir noch überlegen, wie wir die Ressourcen, Privilegien und Rechte in unserer ACL definieren. Hierbei gibt es verschiedene Ansätze. Wir könnten als Ressourcen unsere Models betrachten und deren Methoden als Privilegien einsetzen. Ein anderer Ansatz basiert auf dem Dreigespann Modul, Controller und Action. Diesen Ansatz möchte ich hier vorstellen. Als Privilegien verwenden wir die Namen der Aktionsmethoden und als Ressourcen die Namen der Action-Controller Klassen. Und wo bleibt das Modul? Ganz einfach, für jedes Modul erstellen wir eine eigene ACL. Dies hat auch den Vorteil, dass die ACL insgesamt nicht zu groß wird. Zudem können wir durch geschicktes Cachen der Zend_Acl Objekte zusätzlich die Performance steigern.

Hier folgt als Beispiel die ACL für unser CMS Modul. Die ACLs für die anderen Module sehen ähnlich aus und tragen die Klassennamen Default_Acl, Guestbook_Acl und Forum_Acl.

PHP:
  1. class Cms_Acl extends Zend_Acl
  2. {
  3.     public function __construct()
  4.     {
  5.         // Rollen anlegen
  6.         $this->addRole(new Zend_Acl_Role('guest'));
  7.         $this->addRole(new Zend_Acl_Role('editor'), 'guest');
  8.         $this->addRole(new Zend_Acl_Role('admin'), 'editor');
  9.        
  10.         // Ressourcen anlegen, jede Ressource entspricht einem Action-Controller
  11.         $this->addResource(new Zend_Acl_Resource('index'));
  12.         $this->addResource(new Zend_Acl_Resource('article'));
  13.         $this->addResource(new Zend_Acl_Resource('tag'));
  14.         $this->addResource(new Zend_Acl_Resource('comment'));
  15.        
  16.         // Privilegien und Rechte für Gäste anlegen
  17.         $this->allow('guest', 'index');
  18.         $this->allow('guest', 'article', array('index', 'show'));
  19.         $this->allow('guest', 'tag', array('index', 'show'));
  20.         $this->allow('guest', 'comment', array('index', 'show', 'create'));
  21.  
  22.         // Privilegien und Rechte für Redakteure anlegen
  23.         $this->allow('editor', 'article', array('create', 'update', 'delete'));
  24.         $this->allow('editor', 'tag', array('create', 'update'));
  25.         $this->allow('editor', 'comment', array('update', 'delete'));
  26.        
  27.         // Privilegien und Rechte für Admins anlegen
  28.         $this->allow('admin', 'article', array('approve', 'block'));
  29.         $this->allow('admin', 'tag', array('delete'));
  30.         $this->allow('admin', 'comment', array('mark-as-spam', 'hide'));
  31.     }
  32. }

Das ist keine große Sache und sollte jedem klar sein, der sich mit der Zend_Acl Komponente schon ein wenig befasst hat. Jetzt bleibt die Frage, wann wird die entsprechende ACL denn geladen. Dies kann erst passieren, nachdem das Routing statt gefunden hat und klar ist, welches Modul gerade aufgerufen wird. Dafür verwenden wir ein Plugin.

Das Plugin kümmert sich nur um die Benutzerrechte und nicht um die Authentifizierung. Es geht davon aus, dass diese bereits erfolgt ist. Das Plugin in an sich ist relativ selbsterklärend, hervorheben möchte ich nur, dass auf Basis des aktuellen Moduls der Klassenname der entsprechenden ACL erstellt wird. Der Rest sollte Routine sein. Wenn eine Benutzer nicht über entsprechende Rechte verfügt, wird er als Gast gebeten sich einzuloggen und als angemeldeter User bekommt einen entsprechenden Hinweis.

PHP:
  1. class Default_Controller_Plugin_Acl extends Zend_Controller_Plugin_Abstract
  2. {
  3.     public function routeShutdown(Zend_Controller_Request_Abstract $request)
  4.     {
  5.         // hole Module, Controller und Action
  6.         $module     = $request->getModuleName();
  7.         $controller = $request->getControllerName();
  8.         $action     = $request->getActionName();
  9.        
  10.         // hole Auth
  11.         $auth = Zend_Auth::getInstance();
  12.        
  13.         // hole Rolle
  14.         $role = $auth->hasIdentity()
  15.               ? Zend_Auth::getInstance()->getIdentity()->role
  16.               : 'guest';
  17.        
  18.         // erstelle Klassenname für ACL
  19.         $aclClass = ucfirst($module) . '_Acl';
  20.        
  21.         // Erstelle ACL Objekt
  22.         $acl = new $aclClass(); /* @var $acl Zend_Acl */
  23.        
  24.         // Prüfe Rechte
  25.         if (!$acl->isAllowed($role, $controller, $action))
  26.         {
  27.             // lege neue Action fest
  28.             $newAction = ('guest' == $role) ? 'login' : 'forbidden';
  29.            
  30.             // Ändere Request Objekt für neue Action
  31.             $request->setModuleName('default')
  32.                     ->setControllerName('user')
  33.                     ->setActionName($newAction);
  34.         }
  35.     }
  36. }

Das war es schon im Wesentlichen. Das Ganze ließe sich nun noch verfeinern, indem man sich z.B. eine Factory Methode schreibt, welche das Ermitteln des Klassennamens übernimmt. Dadurch kann die ACL auch außerhalb des Plugins anhand eines Moduls ermittelt werden. Diese Methode könnte My_Acl::factory() heißen, als Parameter $module entgegen nehmen und ein von Zend_Acl abgeleitetes Objekt zurückgeben. Diese Factory-Methode könnte sich dabei auch gleich um das Caching kümmern, so dass die ACLs nicht bei jedem Aufruf neu erstellt werden müssen.

Ich hoffe, die Ausgangsfrage ist somit im Wesentlichen beantwortet. Falls nicht, bitte in den Kommentaren melden. Natürlich auch bei Fragen zu diesem Beitrag.

Tweet this via redir.ec

1. Zend Framework Fragestunde: Abstimmung

Freitag, 16.10.2009

Vor ein paar Tagen habe ich die 1. Zend Framework Fragestunde mit der Fragensammlung eingeläutet. Da ausreichend Fragen eingegangen sind, möchte ich diese nun zur Abstimmung stellen. Die Abstimmung läuft bis Montag, 19. Oktober, um 12 Uhr mittags, Serverzeit. Wenn eine Frage unklar ist, schaut zum einen in dem eben verlinkten Beitrag nach oder fragt in den Kommentaren nach.

Welche Frage soll in der 1. Zend Framework Fragestunde beantwortet werden?

  • Ist es legitim oder nicht, aus einem View-Script auf ein Model zuzugreifen, um Daten geliefert zu bekommen? (10%, 9 Stimmen)
  • Wie erstelle ich am besten ein CMS, welches in der Mitte immer den Inhalt meines Moduls anzeigen, links und rechts sollen aber "Kästchen sein", z.B. wie in diesem Blog hier. (20%, 17 Stimmen)
  • Welche Vorteile und Nachteile besitzt die modulare Verzeichnisstruktur im Vergleich zum konventionellen Aufbau? (10%, 9 Stimmen)
  • Wie testet man die “application/configs/application.ini” (ZF1.9.3) mit PHPUnit? Wie würde der Test für “public/index.php” aussehen? (23%, 20 Stimmen)
  • Wie setze ich eine ACL für eine Modul basierte Applikation um? (37%, 32 Stimmen)

Anzahl der Abstimmer: 87

Und frei nach dem Motto "Jeder nur ein Kreuz": bitte reißt euch zusammen und versucht die Abstimmung nicht zu manipulieren. So etwas machen nämlich nur Mädchen. ;-)

Tweet this via redir.ec

1. Zend Framework Fragestunde: Fragensammlung

Montag, 12.10.2009

Heute möchte ich mit der ersten Zend Framework Fragestunde starten. Letzte Woche hatte ich die Idee in den Raum gestellt und die Resonanz war recht positiv. Wir dort schon beschrieben, wird die Fragestunde immer in mehreren Schritten durchgeführt werden, und der erste Schritt ist logischer Weise die Sammlung der Fragen. Das machen wir heute. Danach erstelle ich eine Umfrage und ihr könnt für Eure Lieblingsfrage abstimmen. Wenn das Ergebnis fest steht, werde ich diese so gut ich kann beantworten. Natürlich kann das Ergebnis dann auch von allen diskutiert werden.

Es gibt ein paar Punkte, die mir für die Zend Framework Fragestunde wichtig sind, damit es in eine einigermaßen geordneten Rahmen ablaufen kann. Man kann es auch Regeln oder Rahmenbedingungen nennen. Oder halt das Kleingedruckte...

  • Bitte erwartet keine vollständig aus programmierten Lösungen für eure Fragen. Das ließe sich in meiner Freizeit kaum bewerkstelligen. Wenn ich selber einen passenden Code-Schnipsel parat habe, werde ich den aber natürlich nicht vorenthalten. Bitte erwartet auch bei sehr konkreten Fragen zu ganz speziellen Problemen keine Wunderlösungen.
  • Eine Frage sollte auch nicht aus Hunderten oder gar Tausenden Zeilen Programmcode bestehen, der nicht funktioniert, so dass ich den Fehler für euch finden soll. Da sind die Mailinglisten oder das Zend Framework Forum der bessere Ort, um fundierte Antworten zu erhalten.
  • Für die Abstimmung werde ich maximal 5 bis 6 Fragen auswählen, damit die Abstimmung auch etwas bringt. Fragen, die unbeantwortet bleiben oder nicht zur Abstimmung gestellt wurden, können bei der nächsten Fragestunde gerne wiederholt werden. Wenn bei der Abstimmung zu den Fragen offensichtlich manipuliert wird, fliegt diese raus bis zum nächsten Mal. Danach beginnt der Zyklus wieder von Vorne.
  • Gerne können auch Gastautoren eine Frage beantworten, wenn diese ihrem Spezialgebiet entspricht.
  • Beispiele für Fragen könnten sein:
    • Wie programmiere ich eine Authentifizierung per Plugin?
    • Wie erstelle ich einen eigenen View-Helper, der mir dies das und jenes ausrechnet?
    • Was muss ich bei der Programmierung eines wiederverwendbaren Moduls beachten?
  • Eine Frage darf übrigens nicht länger als 200 Zeichen lang sein. Warum? Weil das Abstimmungstool nur 200 Zeichen pro Abstimmungspunkt zulässt. Wenn wir aber im Laufe der Fragestunde merken, dass 200 Zeichen doch wenig sind, werde ich mir etwas überlegen.

Und nun kann es los gehen. Die Arena ist eröffnet und ihr könnt eure Fragen stellen. Ich möchte jetzt erst einmal keinen festen Termin geben, bis wann die Fragen eingegangen sein sollten. Das hängt auch vom Feedback ab. Aber bis Mittwoch (14.10.) werde ich auf jeden Fall warten.

Tweet this via redir.ec

Zend Framework Fragestunde

Montag, 05.10.2009

Die Idee für eine Zend Framework Fragestunde wurde ursprünglich auf der PHP Unconference geboren. Dort hatte ich für den Sonntag eine Session mit dem gleichen Namen vorgeschlagen. Die Session ist nur leider in einem Stechen mit einer fehlenden Stimme gescheitert. Viel vorbereitet hatte ich nicht, denn die Idee war es, auf die Fragen zum Zend Framework aus dem Publikum möglichst schlaue passende Antworten zu geben. Ob dieses Experiment in der Praxis funktioniert hätte, weiß ich nicht, das finden wir frühstens bei der nächsten PHP Unconference heraus.

Da das Warten bis dahin aber recht lange dauern wird (schließlich fand die letzte PHP Unconference ja gerade erst vor ein paar Wochen statt), starte ich den Versuch nun einmal in diesem Blog. Wir werden dann sehen, ob dies klappt, denn schließlich gibt es für gezielte Fragestellungen ja bereits die diversen offiziellen Mailinglisten und das sehr gute Zend Framework Forum. Dennoch ist es einen Versuch wert, denke ich. Falls es nicht klappt, machen wir halt etwas anderes auf diesem Blog.

Zur Fragestunde ein paar Punkte, die mir wichtig sind:

  • Bitte erwartet keine vollständig aus programmierten Lösungen für eure Fragen. Das ließe sich in meiner Freizeit kaum bewerkstelligen. Wenn ich selber einen passenden Code-Schnipsel parat habe, werde ich den aber natürlich nicht vorenthalten. Bitte erwartet auch bei sehr konkreten Fragen zu ganz speziellen Problemen keine Wunderlösungen.
  • Eine Frage sollte auch nicht aus Hunderten oder gar Tausenden Zeilen Programmcode bestehen, der nicht funktioniert, so dass ich den Fehler für euch finden soll. Da sind die Mailingliste oder das Forum der bessere Ort, um fundierte Antworten zu erhalten.
  • Die Fragestunde erfolgt immer in drei Schritten. In Schritt 1 stelle ich einen Blogbeitrag ein und ihr könnt in den Kommentaren eure Fragen stellen. In Schritt 2 werde ich dann einige der Fragen zur Auswahl stellen und eine Abstimmung durchführen lassen. In Schritt 3 wird dann die Frage mit den meisten Stimmen von mir nach bestem Wissen und Gewissen beantwortet. Wird eine Abstimmung zu einer Frage offensichtlich manipuliert, fliegt diese raus bis zum nächsten Mal. Danach beginnt der Zyklus wieder von Vorne.
  • Gerne können auch Gastautoren eine Frage beantworten, wenn diese ihrem Spezialgebiet entspricht.
  • Beispiele für Fragen könnten sein:
    • Wie programmiere ich eine Authentifizierung per Plugin?
    • Wie erstelle ich einen eigenen View-Helper, der mir dies das und jenes ausrechnet?
    • Was muss ich bei der Programmierung eines wiederverwendbaren Moduls beachten?

Ok, das waren meine Gedankengänge dazu. Was haltet ihr davon? Supergummigut oder absoluter Blödsinn? Hättet ihr solche Fragen? Euer Feedback ist erbeten!

Tweet this via redir.ec


Better Tag Cloud