Modele i formularze Zend Framework – automatyzacja zapisu
Na codzień pracuję w Zend Framework. Praca jest bardzo przyjemna, framework jest fajnie napisany, obiektowo, elastycznie (wiele klas można rozszerzyć, jest wiele miejsc, w których domyślne klasy są gotowe do uruchomienia naszego kodu, itp.). Ale ma też wiele wad i braków, które często są rozwiązane w innych frameworkach. Twórcy ZF wiedzą o wielu z nich i obiecują, że szykowana wersja 2.0 będzie lepiej przemyślana i napisana. Ale póki nie mamy wersji 2.0 (a nawet jak będzie, nie wiadomo, czy wszystkie problemy zostaną weliminowane) trzeba sobie jakoś radzić. Jednym z problemów, które spotykam w niemal każdym projekcie, jest mechanizm zapisywania danych wysłanych przez użytkownika.
Generalnie zapisywanie informacji w większości przypadków wygląda bardzo podobnie: po wejściu na stronę użytkownik otrzymuje formularz, który wypełnia i zatwierdza; jeśli dane przesłasne są poprawne są zapisywane do bazy (tworzony jest nowy obiekt lub aktualizowany istniejący); jesli niepoprawne – użytkownik otrzymuje ten sam formularz z wpisanymi już wcześniej danymi i komunikatami o błędnych danych. Bardzo często powtarzający się schemat. Czemu więc nie ułatwić sobie życia?
Co jest potrzebne? Formularz, widok, kontroler i model.
Formularz powinien zapewniać (poza wyświetlaniem formularza) pełną walidację i filtrowanie danych. Np. edycja danych kotantaktowych, która zawiera między innymi email i telefon powinna sprawdzać oba pola. Do emaila jest klasa w Zendzie, numer telefonu może być np. wyrażeniami regularnymi. Pola obowiązkowe, listy (np. państw czy województw) itp. – to wszystko sprawa formularza i wiele narzędzi przydatnych w tym temacie jest już w Zendzie. Klasę formularza do kontrolera można tworzyć osobno albo korzystać z plików konfiguracyjnych (ini, xml) na podstawie których Zend potrafi taki formularz przygotować (niżej opisany kontroler korzysta z pierwszego sposobu).
Widok – tu wystarczy
|
1 |
<?php echo $this->form; ?> |
jeśli pod form przypisany jest obiekt klasy Zend_Form. To co przed i po formularzu można dopisać. Za wyświetlanie/renderowanie formularza powinnien odpowiadać obiekt i jego dekoratory. W ostateczności można uciec się do dekoratora ViewScript, ale nadal w widoku akcji kodu formularza nie ma.
Jeżeli w całej aplikacji będziemy stosowali podobne nazewnictwo akcji i parametrów, to każdy kontroler może dziedziczyć wszystko po jednym – wspólnym. Ja polecam napisanie takiego kontrolera abstrakcyjnego, który będzie działał z domyślnymi akcjami create i update, a w kluczowych miejscach będzie wykonywał opcjonalne metody, które w konkretnych kontrolerach można rozszerzać: (1) przed edycją, (2) po edycji z sukcesem, (3) po edycji z błędami.
Przykład kontrolera:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 |
<?php abstract class Application_Controller_Action extends Zend_Controller_Action { /** * @var string */ protected $_suffixNameByController; /** * @return string */ protected function _getSuffixNameByController() { if(null === $this->_suffixNameByController) { $controllerName = $this->getRequest()->getControllerName(); $filter = new Zend_Filter_Word_UnderscoreToCamelCase(); $this->_suffixNameByController = $filter->filter($controllerName); } return $this->_suffixNameByController; } /** * @param array $nameParts * @return string */ protected function _getPrefixedNameByController($nameParts) { $nameParts = (array)$nameParts; $nameParts[] = $this->_getSuffixNameByController(); return implode('_', $nameParts); } /** * @return string */ protected function _getDbTableNameByController() { return $this->_getPrefixedNameByController(array('Application', 'Model', 'DbTable')); } /** * @return Application_Model_DbTable */ protected function _getDbTableByController() { $dbTableClass = $this->_getDbTableNameByController(); return new $dbTableClass; } /** * @return string */ protected function _getFormNameByController() { return $this->_getPrefixedNameByController(array('Application', 'Form')); } /** * @return Zend_Form */ protected function _getFormByController() { $formClass = $this->_getFormNameByController(); return new $formClass; } /** * @param $row Application_Model * @return void */ protected function _afterSave($row = null) { if(null === $row) { $url = $this->view->url(array( 'action' => 'index', 'id' => null )); } else { $url = $this->view->url(array( 'action' => 'read', 'id' => $row->getId() )); } $this->_redirect($url, array('code' => 303)); } /** * @return Application_Model */ protected function _loadObjectFromId() { $id = (int)$this->_getParam('id'); if($id < 1) throw new Zend_Exception('No valid ID found'); $table = $this->_getDbTableByController(); return $table->find($id)->current(); } /** * @return void */ public function createAction() { $form = $this->_getFormByController(); if($this->getRequest()->isPost()) { if($form->isValid($this->getRequest()->getPost())) { $dbTable = $this->_getDbTableByController(); $row = $dbTable->createRow(); $row->setFromArray($form->getValues()); $row->save(); $this->_afterSave($row); } } $this->view->assign(array( 'form' => $form )); } /** * @return void */ public function updateAction() { $row = $this->_loadObjectFromId(); $form = $this->_getFormByController(); if($this->getRequest()->isPost()) { if($form->isValid($this->getRequest()->getPost())) { $row->setFromArray($form->getValues()); $row->save(); $this->_afterSave($row); } } else { $form->populate($row->toValues()); } $this->view->assign(array( 'row' => $row, 'form' => $form )); } } |
Klasa „zgaduje” nazwę formularza i modelu tabeli na podstawie nazwy kontrolera w zapytaniu, więc używając standardowych nazw i operacji, akcje create i update można w końcowych kontrolerach pominąć. Służą do tego pierwsze metody w klasie. Są rozbite na mniejsze, ale zawsze uważam, że dobrze być przygotowanym – sama nazwa klasy formularza może też być potrzebna.
Przy edycji obiektu, ID należy przekazać w parametrze id, np. http://www.example.com/article/update/id/563.
Na koniec zostaje jeszcze model.Powyższy kontroler wykorzystuje standardowe metody ZF – createRow() i setFromArray(array()). W klasie wiersza można nadpisać metodę setFromArray() gdyby np. było potrzeba zapisać dane z innych tabel (połączenie z inną tabelą, itp.) – rzeczy, które wyświetla i sprawdza formularz, a kontroler nie musi nie powinien się już tym zajmować.
Co po zapisaniu danych? Uruchamiana jest metoda _afterSave(), która domyślnie przekierowuje do akcji read z ID ustawionym na ID zapisanego właśnie wiersza (wymaga w nim metody (getId()), ale jest przygotowana na bycie nadpisaną i wykonanie cokolwiek będzie potrzebne w danym projekcie/kontrolerze.
Jak tego użyć? Jeżeli będziemy trzymali się w projekcie kilku zasad (dziedziczenie odpowiednich elementów po odpowiednich klasach) w naszym kontrolerze do edycji danego elementu (typu PostsController, UsersController, BooksController) możemy całkiem pominąć akcje create i update używając generycznych. W razie potrzeby poprawki – zmiany dokonujemy w jednym miejscu. Magia programowania obiektowego. Miłego używania!
