Tworzenie Aplikacji Internetowych dr Wojciech M. Gańcza 1

Cel Nauczenie się tworzenia aplikacji Wypracowanie metod pracy nad większym programem Poznanie metod i metodologii używanych w praktyce programistycznej Wykształcenie umiejętności pisania w sposób prosty, jasny i możliwy do poprawiania nie tylko przez autora

A co celem nie jest Nauczenie znaczenia poszczególnych znaczników HTML. To jest dostępne w podręcznikach Zapamiętanie jakie elementy dopuszczają jakie atrybuty CSS2 Poznanie całej struktury DOM dla JavaScript-u Nauczenie się budowania złożonych zapytań w języku SQL

Plan pracy Wybór zagadnienia Wybór narzędzi Przygotowanie programu (w pętli) Analiza problemu Prototypowanie Testowanie Programowanie funkcjonalności Testy funkcjonalne Testy akceptacyjne

Wybór zagadnienia Aby nauczyć się budowy aplikacji – powinniśmy pisać aplikację – a więc nie stronę lub strony internetowe. Nie bazę danych z interfejsem – ale aplikację. Zagadnienie powinno być proste – ale nietrywialne. No i przydatne. Proponuję: Program do obsługi giełdy podręczników szkolnych

Wybór narzędzi Środowisko serwerowe: LAMP Linux, Apache, MySQL, PHP Dowolny edytor tekstowy do edycji kodu źródłowego System kontroli źródeł (SVN ?) Przeglądarki – kilka!

Pierwsza analiza problemu Uczniowie powinni wiedzieć jakie książki powinni kupić – lista książek powinna być zintegrowana z programem. Uczniowie powinni mieć możliwość sprzedawania niepotrzebnych książek i kupowania potrzebnych. Zmiana klasy powinna być prosta, bez konieczności zaznaczania i odznaczania książek.

Analiza -wyniki Podręczniki są pogrupowane w listy Uczeń może dołączyć sobie dowolną liczbę list podręczników Program prowadzi rejestr książek które użytkownik aktualnie posiada Zmiana przypisania do list nie może zmienić stanu posiadania książek Program pozwala na wyświetlenie czy książka jest potrzebna czy nie

Przypadki użycia Zamiast rozpisywać wszystkie możliwości akcji jakie może wykonać użytkownik będziemy rozpatrywać jedynie przypadki użycia. Wyniki analizy zapiszemy jako konkretne akcje użytkownika oraz wyniki jakie wyświetli program Implementujemy te przypadki użycia które są istotne i popularne.

Przypadek użycia nr 1 Użytkownik włącza aplikację Aplikacja wyświetla listę książek zaznaczając które książki użytkownik potrzebuje, których z nich nie ma, a także które książki ma, a są mu niepotrzebne. Użytkownik w poczuciu bycia dobrze poinformowanym – wyłącza aplikację.

Prototyp Reguła: Każdy pisany program jest dla autora pełen niespodzianek i nowości. Gdyby było inaczej – byłby już napisany a więc praca nad nim byłaby całkowicie niepotrzebna. Jeśli czegoś nie znamy – musimy to poznać – najlepiej próbując. Takie próby nowych technologii, testy funkcjonalności funkcji, elementów języka i bibliotek – to prototypy

Prototyp c.d. Budując prototyp sprawdzamy środowisko. Warto więc przygotować prototyp który sprawdzi czy działa PHP, czy przeglądarka interpretuje style napisane w formacie CSS2 i czy działa połączenie z bazą danych Prototypy nie muszą być pisanie porządnie – są tylko po to by sprawdzić czy umiemy coś zrobić ŻADNEGO PROTOTYPU NIE KASUJEMY !

Organizacja pracy Nasza aplikacja będzie się rozwijać, i warto zadbać o łatwość jej uruchamiania Oprócz samej aplikacji potrzebujemy: Dostępu do wszystkich prototypów Możliwości szybkiego testowania kodu Tworzenia bazy danych oraz danych testowych Dokumentowania postępu prac Te elementy są także stronami WWW

Organizacja pracy c.d. Każdemu elementowi warto przyporządkować katalog W miarę postępu prac – dodawać będziemy inne katalogi – na przykład na dane do testów importu Aplikację nad którą pracujemy umieszczamy także w podkatalogu – łatwo będzie robić jej kopie dla poszczególnych działających werji aplikacji

Testowanie Testujemy KAŻDĄ możliwą funkcjonalność – łącznie z wyglądem strony Testy piszemy PRZED implementacją Testy to wywołania funkcji i sprawdzenie wyników Testy są przykładem jak używać poszczególnych funkcji i klas Testujemy zawsze CAŁĄ funkcjonalność

Programowanie Wreszcie czas na programowanie – przygotujmy widok listy książek. Wyniki zaprezentujemy w postaci tabelki Dane do tabeli powinny pochodzić z bazy danych – ale na razie bazy nie mamy. Pamiętajmy, że działanie tabeli powinno być testowalne!

Baza danych czy interfejs Dla trzymającego w rękach młotek – każdy problem wygląda jak gwóźdź. Co więc jest najważniejsze w programie? Dobrze wyglądający i wygodny interfejs użytkownika ? Poprawnie zaprojektowana i efektywna baza danych ? A może coś innego …

Porządnie – czyli obiektowo Wszystkie elementy programu przygotujemy jako klasy. Obiekty możemy wymieniać zachowując interfejsy. Interfejsy powinny udostępniać maksymalną funkcjonalność przy najprostszej konstrukcji Obiekty powinny mieć proste i oczywiste funkcjonalności

Czy to nie będzie zbyt wolne? Możliwe że będzie, ale… Uporządkowany kod pozwoli na łatwą modyfikację programu Szybciej będziemy mogli dokonywać przeróbek Jeśli będzie trzeba aplikację przyspieszyć – można to zrobić bez problemu na koszt klienta :-) Porządków na koszt klienta zrobić się nie da

Pierwsza klasa - Wyjście W języku PHP tekst jest wysyłany do przeglądarki poleceniem echo.

Wyjście – po co nam to? Pisząc wyjście jako klasę – możemy przekierować wyjście – na przykład do tekstu – by go porównać ze wzorcem. W ten sposób możemy testować działanie programu – zamiast wyświetlać wynik – możemy sprawdzać czy wyniki są takie jak być powinny

Wyjście testowe Zamiast porównywać cały tekst – możemy sprawdzić sumę kontrolną Wszystkie elementy które będziemy wyświetlać na ekranie przeglądarki – mogą być sprawdzane. Jeśli cokolwiek napiszemy – dodajemy to od razu do testów – by móc sprawdzać wyniki działania

Wyjście testowe

Interfejsy Warto na początku ustalić podstawowe interfejsy klas. Na początek potrzebujemy dwie klasy: Źródło danych do tabeli – dane które będziemy wyświetlać Formater tabeli – klasa która przerobi dane na opis w języku HTML – a więc wyświetli dane w postaci tabeli

Interfejs wyświetlania Każda klasa której obiekty wyświetlają coś na ekranie przeglądarki maja metodę: function render(&$output) Wyjście przekazujemy przez referencję – to ważne w przypadku wyjścia testowego

Interfejs źródła danych Źródło danych powinno dostarczać dane w postaci tablic – dla każdego rzędu – tablica function get() ; function eof() ; Pierwsza metoda zwraca dane, Druga – informację czy są jeszcze dane.

Podział na pliki Zazwyczaj klasy umieszczane są w oddzielnych plikach Ma to znacznie gdy grupa osób pracuje nad projektem Nazwy plików powinny odpowiadać nazwom klas Jeśli plików jest dużo – używamy katalogów

Klasa GridRenderer Klasa rysująca tabelkę z danych jest bardzo prosta – przekazujemy jej dane w postaci obiektu będącego źródłem danych Ma metodę render – która umieszcza w wyjściu kod HTML zawierający dane z wejścia.

Klasa DataSource Implementuje interfejs źródła danych Nie czyta danych – używa zapisanych na stałe wartości umieszczonych w tablicach. Warto przygotować sobie takie źródło – przyda się później do testów.

Aplikacja Nasza aplikacja ma teraz postać: $out = new Output(); $dat = new DataSource(); $grd = new GridRenderer(&$dat); $grd->render($out); Prawda, że proste?

W kolejnym odcinku… Jak napisać knkretną implementację GridRenderer DataSource Piszemy pierwszy test A może nawet… przygotowujemy środowisko testowe Jak do tabelki dodać nagłówki Pofantazjujemy o formatowaniu danych I wiele, wiele innych…