Niskie progi PHP

Znacie najkrótszy kawał o PHP? Uwaga kawał:

Koniec kawału.

Nie trzeba wiele polotu żeby wyskrobać [code=php]echo „witaj użytkowniku” [/code] Tylko czy ktoś taki może już się nazywać programistą? Ja często tankuję samochód, a nawet czasem doleję oleju i płynu do spryskiwaczy, jednak mechanik ze mnie żaden. Podobnie z PHP – jest to język o tzw. niskim progu wejścia – co nie oznacza,że nie można w nim pisać całkiem fajnych aplikacji i posiadać umiejętności pozwalające nazwać się programistą przez duże P.

Skoro pokonaliśmy próg PHP to chodźmy po schodach w górę:)

Na początek wystarczy znajomość instrukcji echo – kilka innych i możemy budować pierwsze strony interaktywne. Dorzucimy bazę danych i można stworzyć już całkiem sporą aplikację. Ba! Można zrobić prawie wszystko! Tylko co z tego jeśli kod będzie wielki, wymieszany z HTML-em i będziemy wszystko pisać liniowo? Trzeba troszkę rozwinąć nasze umiejętności. Kolejnym krokiem niech będą funkcje i i rozbicie na pliki. O zgrozo! - pomyślał każdy, kto przedzierał się przez kod strony napisany na includach. Taka struktura jest sztywna i nie przejrzysta – dodatkowo includowanie kolejnych stron zaciemnia kod, mimo że można zachować porządek w takiej strukturze, często wprowadzanie zmian jest kłopotliwe, nie wspominając o przenoszeniu fragmentów kodu. Także zasięg zmiennych jest zbyt duży,co może prowadzić do poważnych błędów. Myślę, że właśnie przez to, że wiele stron jest pisanych w wyżej opisany sposób, PHP zyskał taką złą sławę. Można jednak iść dalej i poprawiać swój kod, wybierając programowanie obiektowe, które uporządkuje nasz kod php i zamknie zmienne w odpowiednich zakresach.

Zatrzymajmy się na chwilę i przypomnijmy jak działa serwowanie po internecie. W istocie jest to prosty schemat: przeglądarka wysyła żądanie, serwer zwraca odpowiedź i tak w kółko. W najprostszym podejściu przeglądarka żąda dokumentu php/html, a serwer go zwraca – wysyłany jest adres dokumentu, i otrzymujemy jego zawartość. Proste. Struktura aplikacji oparta na adresach katalogów jest sztywna, a wprowadzanie zmian trudne – przydałoby się coś, dzięki czemu prościej i bardziej efektywnie wybieralibyśmy którą stronę otworzyć i nie musielibyśmy trzymać się przy tym struktury katalogów – to właśnie jest celem routingu. Żądanie odwołuje się do jednego pliku php który decyduje, jaką stronę wyświetlić i co w ogóle zrobić. Dzięki temu lepiej możemy zorganizować strukturę katalogów, umieszczać klasy w odpowiednich dla nich miejscach, prościej zorganizować adresy URL. Żądanie, odpowiedź, żądanie odpowiedź, żądanie odpowiedź..... I przeglądarka pięknie wyświetla stronki – no ale jak te stronki tworzyć? Za każdym razem kopiować nagłówek, stopkę i podmieniać środek?? Nie wydaje mi się żeby to było optymalne rozwiązanie. O wiele lepiej będzie rozbić layout na kilka części np. foot, head, content i dołączać te części. Należy też oddzielić logikę od wyświetlania- to bardzo ważne żebyśmy mieli przejrzysty kod. Logikę wydzielimy do oddzielnych plików – nazwijmy je hmmmm.... może by tak kontrolerami? Natomiast html niech nazywa się – no nie wiem,nie wiem.... Widok?

Przy czym widoki możemy tworzyć jako pliki php z includami, ale mogli byśmy skorzystać też ze smartów albo Twigów itp.- więcej w temacie może następnym razem. Po tych zmianach schemat wygląda tak: żadanie-> główny plik PHP(decyduje które akcje wykonać) -› kontroler( przetwarza dane i przesyła wynik do widoku) -› widok wyświetla stronę.

Pod pojęciem „przetwarza dane” - kryje się jeszcze za dużo, bo oprócz tzw. logiki biznesowej znajduje się tu też interakcja z bazą danych, przez co nasz kod wymieszany jest z zapytaniami SQL i operacjami na rekordach bazy danych. Można te funkcjonalności rozbić i utworzyć coś, co będzie się zajmowało interakcją z bazą danych, a w kontrolerze zajmiemy się tylko logiką. Byt odpowiedzialny za interakcję z bazą danych nazywa się Modelem – dzięki modelowi następuje odseparowanie części odpowiedzialnej za bazę danych od czystej logiki i zamiast w kontrolerze mieć „insert into dobre_komentarze ….” możemy mieć na przykład „$komentarze->dodajNowy(..”. Prawda że lepiej? Jeśli wydaje ci się to w tej chwili zbyteczne, to na pewno doceniłbyś takie podejście, w momencie wprowadzania zmian w aplikacji. (Model View Controller to oczywiście nie mój wymysł tylko podstawowy wzorzec projektowy)

To dopiero wierzchołek tego, co „programista PHP” umieć powinien. Aplikacja PHP mocno różni się od javy,c++ , c# czy innych – główną różnicą nie jest składnia języka, ale przebieg aplikacji.”Normalnie” po odpaleniu aplikacji rusza najczęściej main loop – pętla która reaguje na wszystkie zdarzenia i steruje przepływem aplikacji. Użytkownik kończy taką aplikację zamknięciem okna, lub w podobny sposób.W międzyczasie wszystkie utworzone obiekty, dane, i powiązania mogą być dostępne w pamięci komputera, i gubią się dopiero z końcem życia aplikacji. W PHP cały cykl zawarty jest pomiędzy żądaniem i odpowiedzią – nie ma nic więcej i nie ma „programu pomiędzy” wywołaniami, a mimo to ciągłość nawigacji po stronach musi być zachowana. Pociąga to za sobą szereg konsekwencji, jak konieczność używania sesji, ciasteczek, ciągłego kreowania obiektów itd. Jest to czynnik, który potrafi komplikować tworzenie aplikacji. Kolejnym takim czynnikiem jest jej dostępność – najczęściej aplikacja dostępna jest z wielu komputerów i dla każdego, przez co narażona może być na więcej ataków niż plik exe siedzący na komputerze lokalnym. Także zakres działań użytkownika w tradycyjnej aplikacji jest bardziej ograniczony – np. jeśli aplikacja okienkowa posiada jeden guzik, to można tylko go wcisnąć, natomiast, jeśli aplikacja webowa posiada jeden guzik, to nadal można wysłać żądanie inne, niż naciśnięcie tego przycisku, które np. - podmieni wartość przekazywaną przez owy guzik. O tych zagrożeniach także trzeba pamiętać.

Słyszałem opinię, że ktoś kto nie zna assemblera nie może nazywać się informatykiem, podobna opinia jest o programistach PHP- jeśli ktoś koduje w PHP nie może nazywać się programistą. Mimo, że nie chcę nazywać siebie programistą, to muszę z takimi opiniami się nie zgodzić. Programista PHP nie ma łatwo- okazuje się, że często w jego gestii jest utworzenie schematu bazy danych, design i wszystko inne. Sam HTML, css i javascript to potężna ilość wiedzy, którą także trzeba posiadać. Tworzenie aplikacji webowych to równie duże wyzwanie, co pisanie aplikacji okienkowych, mimo że zdaję sobie sprawę z ułomności php, to uważam że stosując dobre praktyki można tworzyć dobry kod i być Programistą PHP – już bez żartu.

P.S. Jeśli będę miał trochę czasu to napiszę coś o Symfony 2.0 na którym pracuję od lipca i szerzej omówię dotknięte tu kwestie