Technologie tworzenia aplikacji internetowych Wykład 3 dr inż. Piotr Czapiewski Technologie tworzenia aplikacji internetowych Wykład 3

Zend Framework

Web Application Framework Framework (rama projektowa, szkielet) to w programowaniu struktura wspomagająca tworzenie, rozwój i testowanie powstającej aplikacji. Z reguły na framework składają się programy wspomagające, biblioteki kodu źródłowego i inne podobne narzędzia. (Wikipedia) Czym jest framework?

Web Application Framework Wzorce projektowe – MVC, Front Controller Narzucona organizacja kodu, struktura projektu – łatwiejsze utrzymanie projektu Wspomaganie typowych zadań związanych z budową aplikacji internetowych (np. walidacja formularzy, autoryzacja) Generowanie kodu, np. formularzy, scaffolding Testowanie Bogate biblioteki dodatkowe W czym może nam pomóc framework?

Web Application Framework Popularne frameworki PHP Zend Framework Symfony CakePHP Yii CodeIgniter Kohana Inne popularne frameworki Ruby on Rails (Ruby) Django, Pylons (Python) Spring, Struts, Seam (Java) ASP.NET MVC Catalyst (Perl) Grails (Groovy)

Zend Framework Biblioteka dla PHP 5 wspomagająca produktywność programistów aplikacji internetowych Pełna obiektowość Wsparcie wzorca MVC Bogata dokumentacja Zend Framework Convention over configuration Gotowe, proste rozwiązania dla 80% zadań Łatwa rozszerzalność dla osiągnięcia pozostałych 20% Elastyczność – prostota i rozszerzalność

Zend Framework

Model View Controller Model Zapewnia dostęp do danych Zawiera same dane lub mechanizmy dostępu do nich Widok Wyświetla interfejs użytkownika Wyświetla dane pobrane z modelu, przekazane przez kontroler Odpowiedzialny wyłącznie za prezentację informacji Kontroler Przyjmuje żądanie użytkownika, manipuluje modelem, tworzy widok lub powoduje jego odświeżenie Decyduje, jakie operacje wykonać, jakie modele i widoki wywołać

MVC a obsługa żądania HTTP A request comes in to an input controller, which pulls information off the request. It then forwards the business logic to an appropriate model object. The model object talks to the data source and does everything indicated by the request as well as gather information for the response. When it's done it returns control to the input controller, which looks at the results and decides which view is needed to display the response. It then passes control, together with the response data, to the view. The input controller's handoff to the view often isn't always a straight call but often involves forwarding with the data placed in an agreed place on some form of HTTP session object that's shared between the input controller and the view.

Model View Controller Dwa istotne podziały Model ––––––––– Prezentacja Widok –––––––––Kontroler

Model View Controller Rozdzielenie modelu i prezentacji Dwa aspekty programowania Inne problemy, inne punkty widzenia Widok – mechanizmy UI, projekt interfejsu, układ kontrolek Model – logika biznesowa, procesy, interakcja z bazą danych Inne technologie, biblioteki Skrajny przypadek – specjalizacja programistów Kierunek zależności Prezentacja zależy od modelu, ale model od prezentacji nie Rozdzielenie prezentacji i modelu to jedna z najważniejszych zasad dobrego projektowania oprogramowania. Fundamentally presentation and view are about different concerns. When you're developing a view you're thinking about the mechanisms of UI and how to lay out a good user interface. When you're working with a model you are thinking about business policies, perhaps database interactions. Certainly you will use different very different libraries when working with one or the other. Often people prefer one area to another and they people specialize in one side of the line. A key point in this separation is the direction of the dependencies: the presentation depends on the model but the model doesn't depend on the presentation. People programming in the model should be entirely unaware of what presentation is being used, which both simplifies their task and makes it easier to add new presentations later on. It also means that presentation changes can be made freely without altering the model.

Model View Controller (c.d.) Rozdzielenie modelu i prezentacji Prezentacja zależna od kontekstu Różne sposoby prezentacji tego samego modelu Od różnych wariantów kolorystycznych po całkowicie różne interfejsy Zmiana prezentacji nie wpływa na model Ponowne użycie kodu Wielokrotne użycie elementów modelu, także w innych projektach Możliwość udostępnienia usług sieciowych Testowanie Testowanie obiektów niewizualnych jest łatwiejsze Łatwe testowanie całej logiki dziedzinowej bez uwzględniania GUI Depending on context, users want to see the same basic model information in different ways. Separating presentation and view allows you to develop multiple presentations—indeed, entirely different interfaces—and yet use the same model code. Most noticeably this could be providing the same model with a rich client, a Web browser, a remote API, and a command-line interface. Even within a single Web interface you might have different customer pages at different points in an application. Nonvisual objects are usually easier to test than visual ones. Separating presentation and model allows you to test all the domain logic easily without resorting to things like awkward GUI scripting tools

Front Controller vs. Page Controller Rola kontrolera Obsługa żądania HTTP Decyzja – co dalej zrobić z żądaniem? Jakiego użyć modelu i widoku? Dwa wzorce kontroli Page Controller Osobny obiekt kontrolera dla każdej strony lub dla każdej akcji W najprostszym przypadku łączy w sobie role widoku i kontrolera Front Controller Jeden obiekt obsługuje wszystkie żądania Sprawdza parametry żądania i tworzy kolejne obiekty, przekazując do nich sterowanie Scentralizowana obsługa żądań HTTP, łatwiejsze zarządzanie

Front Controller HTTP Client HTTP Request HTTP Response

Instalacja Zend Framework

Instalacja Zend Framework Zawartość ZendFramework-1.10.2-minimal library – pliki tworzące bibliotekę Zend Framework bin – pliki uruchamiane z linii poleceń podczas pracy nad projektem

Struktura projektu w ZF

Zend Tool Narzędzie do tworzenia projektu, dodawania kontrolerów, akcji, formularzy, itp. Wywoływane z linii poleceń zf.php zf.bat (Widnows) lub zf.sh (Linux) Wymagane php.exe w ścieżce systemowej

Tworzenie projektu Wywołanie Zend Tool: Wynik: zf create project nazwa_projektu Wynik: Struktura katologów Kontrolery: IndexControler ErrorController Widoki: index.phtml error.phtml

Budowa kontrolera <?php class IndexController extends Zend_Controller_Action { public function init() { /* Initialize action controller here */ } public function indexAction() { // action body } }

Kontrolery i akcje Klasy kontrolera Klasa kontrolera musi dziedziczyć z Zend_Controller_Action Nazwa klasy powinna kończyć się słowem Controller, np.: IndexController, ErrorController Zachowanie konwencji nazw plików i klas jest konieczne do poprawnego działania aplikacji

Widoki Katalog widoków Plik widoku Widoki odpowiadające kontrolerowi IndexController umieszczamy w katalogu: application/views/scripts/index/ Widok dla akcji indexAction umieszczamy w pliku: index.phtml Plik widoku Zwykły plik PHP – mieszanka HTML i PHP Kod PHP ograniczamy do niezbędnego minimum związanego z wyświetlaniem danych

Uruchamianie projektu Katalog publiczny /public Powinien być jedynym katalogiem udostępnianym przez WWW Początkowo zawiera pliki: .htaccess index.php Wymagane włączenie mod_rewrite na serwerze

Plik .htaccess Ustawienie środowiska aplikacji SetEnv APPLICATION_ENV development RewriteEngine On RewriteCond %{REQUEST_FILENAME} -s [OR] RewriteCond %{REQUEST_FILENAME} -l [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^.*$ - [NC,L] RewriteRule ^.*$ index.php [NC,L] Ustawienie środowiska aplikacji Włączenie silnika mod_rewrite Przekierowanie wszystkich żądań do index.php

Uruchamianie projektu Adresowanie kontrolerów w URL Załóżmy, że katalog publiczny umieszczony jest na serwerze WWW i widoczny pod adresem: http://localhost/zf_01/public/ Ścieżka do kontrolera IndexController: http://localhost/zf_01/public/index/ Ścieżka do akcji indexAction w kontrolerze IndexController: http://localhost/zf_01/public/index/index

Uruchamianie projektu Aplikację uruchamiamy wchodząc na adres katalogu publicznego http://localhost/zf_01/public/

Przekazywanie danych do widoku Odebranie danych z żądania HTTP $x = $this->getRequest()->getPost('zmienna'); Dostęp do widoku z poziomu kontrolera: $this->view Ustawienie zmiennej w widoku: $this->view->zmienna = $x;

Przekazywanie danych do widoku controllers/IndexController.php public function indexAction() { $this->view->napis = "Ala ma kota"; } views/scripts/index/index.phtml <h1>Witamy w Zend Framework</h1> <?php echo $this->napis; ?>

PHP – Member overloading

PHP – Member overloading Znaczenie inne niż w większości języków obiektowych Metoda dynamicznego tworzenia pól i metod „Magiczne metody” __get(), __set(), __isset(), __unset() Wywoływane automatycznie przy próbie dostępu do nieistniejącego lub ukrytego pola (private, protected)

Przykłady stosowania w Zend Przekazywanie danych z kontrolera do widoku Przechowywanie danych w modelu Równocześnie dostęp obiektowy i łatwy zapis do bazy

Literatura Zend Framework Manual http://framework.zend.com/manual/en/ Tomasz Skaraczyński, Andrzej Zoła: PHP5. Programowanie z wykorzystaniem Symfony, CakePHP, Zend Framework. Helion 2009 M. Fowler et al.: Patterns of Enterprise Application Architecture. Addison Wesley 2002