<title> <?=$tytul?> </title>
czy
<title>${tytul}</title>
Jakiś piekielnie skomplikowany mechanizm, który dba o przekazywanie zmiennych do odpowiednich plików, dodatkowo o to, aby to wszystko pozamieniać, generując tylko narzuty czasowe ... więc o co chodzi ?
Ale może najpierw co to jest MVC. Za wikipedią:
MVC (ang. Model-View-Controller - Model-Widok-Sterownik) to wzorzec projektowy w informatyce, którego głównym założeniem jest wyodrębnienie trzech podstawowych komponentów aplikacji:Czyli tak dla ludzi. Chodzi o to, aby jak najbardziej oddzielić logikę prezentacji PHP od logiki kontrolera HTML (tak w dużym uproszczeniu). No tak miało być dla ludzi. Otóż chodzi o to aby oddzielić to co skrypt robi od tego jak skrypt to pokazuje. Ja sam sobie mówiłem: "Ale co to za problem ... przecież <php? include ('licznik.php'); ?> czy <php? $licznik->show(); ?> nikomu jeszcze nie zaszkodziło !".
- modelu danych,
- interfejsu użytkownika,
- logiki sterowania
Jednak nie o takie podejście w całym tym przedsięwzięciu chodzi. Aby mówić o MVC trzeba po prostu dojrzeć do niego - inaczej to będzie wciskanie ci "dobrego" rozwiązania, do którego w cale nie jesteś przekonany i jest Ci wciskane na siłę ! :)
Moim ideałem programowania jest pewien ideał nabyty z C++. Jeżeli piszę klasę, to chcę ją napisać tak, aby ktoś sobie wziął pliczek z moją klasą skopiował do swojego katalogu, includował i już mógł jej używać - jak swojej. Tak też starałem się robić w PHP - i tu pojawia się problem - oprócz PHP jest przecież ... HTML :|. No właśnie :| W C++ sprawa jest prosta, możemy nie martwić się o "prezentację danych" (pod konsolą) robimy cout. A jeszcze lepiej zwracamy po prostu wynik nic nie wyświetlając. Jednak w PHP Dochodzi HTML. Opowiem wam historyjkę z życia wziętą.
Musiałem kiedyś przerobić portal oparty o XOOPSa. Chodziło o zmianę layoutu. Kiedy zagłębiłem się w kod okazało się, że jego fragmentu porozrzucane są po najróżniejszych zakamarkach tabel baz danych ... Uwierzcie ! grzebanie i dochodzenie w jakim rekordzie znajduje się ten konkretny fragment MENU doprowadzało mnie do szału ! A wyobraźcie sobie, że poza tym kod HTML mógłby być porozrzucany po najróżniejszych metodach używanych tam klas... po prostu masakra ! W takiej sytuacji prosty plik HTML z jasno powstawianymi elementami pochodzącymi z PHP byłby idealny zamiast grzebanie się po metodach klas i bazie danych - udręka !
O wiele łatwiej jest stworzyć własny formularz do bazy danych mając:
<form action="${action}" method="${method}">
<fieldset>
<legend>${tytul}</legend>
<label>${login}: <input name="${login}" type="text"></label>
</fieldset>
</form>
niż jakąś czarną skrzynkę pod tytyłem:
$login->pokaz_formularz();
Niby też ładnie, ale dla osoby, która chciałaby nasz formularz zupełnie przerobić (bo nie pasuje Jej do jego layout) kompletnie nie pasuje. Wtedy znacznie łatwiej jest powstawiać sobie kilka pól (nasze zmienne ${nazwa}) w nowe miejsca, do przez siebie przygotowanego pliku niż szukać po klasach i bazie danych - gdzie on mógł to wcisnąć ?
A więc klasa musi się już tylko zająć przetworzeniem danych i wrzuceniem ich w odpowiedni szablon. Może to wyglądać na przykład tak:
$zmienne = array {
'tytul' => 'Moje MVC',
'nazwa' => 'firma',
}
$controller->parse('formularz.html', $zmienne);
No i tu pojawia się kolejny element. Kontroler - czyli element, który zajmie się włożeniem odpowiednio przez nas wcześniej napisanych zmiennych w odpowiedni szablon HTML.
Z praktycznego punktu widzenia wygląda to tak:
- HTML - zajmuje się formą w jakiej prezentowane są dane.
- PHP - naprawdę zajmuje się tylko obróbką danych.
- Jakiś parser - czyli klasa (albo funkcja, czy co tam sobie chcecie) zajmuje się tym, żeby włożyć suche zmienne PHP w odpowiednie miejsca w pliku HTML.
No właśnie i tu pojawia się kolejna kwestia. Framework. O co chodzi ? Myślę, że wiele osób pisząc o MVC zaczyna pisać o jakimś konkretnym frameworku i przez to wprowadza tylko bałagan, gdyż framework to pojęcie o wiele szerszym znaczeniu.
Framework to tak po ludzki napisany w jakimś języku mechanizm, zbiór biblitotek, którego używa się jak języka programowania... czyli buduje się w opraciu o nie swój kod. To znaczy tak jakbyś napisał swój własny język programowania w PHP i go opublikował. Na początku wydawało mi się to głupotą do kwadratu ! Po co mi język napisany w PHP do obsługi PHP. Żadnych więcej możliwości nie daje, a tylko powoduje, że wszystko działa wolniej ... głupie. A jednak nie zawsze, tylko trzeba wiedzieć kiedy z niego korzystać, a kiedy nie. A powodów może być kilka.
Frameworki pisane są do różnych języków programowania np. do JavaScript i jedną z korzyści z nich wynikających opiszę właśnie na tym przykładzie. Dwa dobrze znane mi frameworki w JavaScript to jquery i prototype. Ładuje się do przeglądarki pliczek w poprzez na przykład i ... pisząc w JavaScript od tej pory ma się dwie możliwości. Albo używamy JavaScript, albo używamy framework-a...
Przykładowy kod, który powoduje zniknięcie elementu na stronie (będzie to element ) w jquery wygląda następująco.
$('div.cos').hide('slow');
i tyle ! Proste nie ? Teraz zastanów się. Gdybyś nie używał jquery jak chciałbyś to zrobił ? Ja nie wiem... Jednak wiem jedno - znając burzliwe dzieje przeglądarek internetowych pisząc w JavaScript wcześniej czy później natknąłbym się na moment, w którym coś pod konkretną przeglądarką przestałoby działać ... :( Byłbym wtedy zmuszony do próby zaprogramowania tego samego na dwa, a może nawet trzy czy cztery (a może nawet więcej) sposobów, tylko po to aby obsłużyły to wszystkie przeglądarki... Powiedzmy, że się udało - napisałem skrypt... przychodzi rok 2008 i na rynku pojawia się kIEpska 8 nie zgodna z niczym ... i mój skrypt nie działa :( i co znowu siadam do kodu i rzeźbię ....
I tu pojawia się nasz framework. Działa jak język programowania, czyli pozwala nam pisać program... pod spodem jednak siedzą rzeczywiste funkcje JavaScript, które wszystko robią za nas :) Jaki jest z tego plus - nie my, ale twórcy frameworka zadręczają się problemem "nie działa na nowej przeglądarce :(" My piszemy nasz kod RAZ, wrzucamy na stronę, a o zgodność i całą resztę martwi sie framework :) i działa. Takie rozwiązanie (w przypadku JavaScript) ma wiele więcej plusów. Wymienię kilka:
- Nie obchodzi nas jak obsługiwana jest wersja JS w przeglądarce.
- Nie martwimy się gdy wychodzi nowy standard JS - o to martwią się twórcy frameworka.
- Nie martwimy się gdy wychodzi nowa przeglądarka. Czekamy aż wyjdzie nowa wersja frameworka, podmieniamy jeden pliczek z nim zawarty i wszystko działa :)
Dlatego wybierając framework należy zwrócić uwagę na kilka drobiazgów:
- Jak często aktualizowany jest framework i czy w ogóle jest jeszcze rozwijany.
- Jak wygląda jego dokumentacja i czy jest często wykorzystywany.
Dodatkowo w JS frameworki mogą oferować obsługę fajnych efektów, animacji, składnię dużo przejrzystrzą i prostą aniżeli samo JS (dużo łatwiej czytać kod), kod może być w nich krótszy i bardziej zwięzły. Często framework posiada dodatkowe możliwości i dostępne w sobie użyteczne algorymty, których na próżno szukać w suchym JavaScript. Nie musimy wtedy pisać własnych funkcji. Przykładowo w jquery obsługa AJAXa jest bajecznie prosta a kod obsługujący go jest bajecznie prosty, przejrzysty i pisze się całkiem przyjemnie :) Nie martwię się o to, że AJAX w IE obsługiwany jest totalnie inaczej niż w FireFox czy w Operze, nie muszę też zagłębiać się też wszczegóły techniczne i sposób działania. Piszę sobie:
$('div.tresc').load('rozdzial.php?rozdzial=1');
a w uzyskanym dzięki frameworkowi czasie piję sobie kakao ;)
Istnieją też frameworki do PHP. Starają się one eliminować niedogodności języka oraz platform, na których jest uruchamiany. Dostarczają także użytecznych mechanizmów, które często są wykorzystywane w programowaniu, a które nie jeden z nas musiałby opracowywać na własną rękę:
- Często nie wiemy na jakim PHP będziemy pracować, albo przychodzi nam zmienić serwer. Wszystko było napisane w PHP 5, funkcje czystego DOMu działały świetnie a tu klops :( usługodawca zapodaje na serwer PHP4 a my ... kwiczymy. Może przyjść nam tutaj z pomocą framework ! Jeżeli jest tak zaprogramowany piszemy mu wtedy "php5" i kod napisany we frameworku działa używając funkcji z php5. Zmienia się sytuacja musi działać na php4 podajemy frameworkowi "php4" i działa na php4. Zmieniamy tylko jedną literkę ! zamiast kilkuset linijek aplikacji.
- Frameworki, także te w PHP mogą wspomagać programowanie od strony baz danych czy AJAX-a (np. symfony wspiera AJAX). Przykładowo baza danych - zmieniamy silnik z MySQL na Postgresa ... Framework może oferować nam swoją własną klasę dostępu do bazy danych, która działa tak samo bez względu na to z jakiego mechanizmu bazodanowego korzystamy.
- Jeżeli pojawi się PHP 6 ... to my nadal pracujemy w naszym frameworku a o poprawność męczą się ludzie tworzący go.
- Często framework wspomaga programowanie w MVC udostępniając nam klasy, które w sprytny i zgrabny sposób potrafią przetransportować informacje z klasy do odpowiedniego szablonu w PHP i powstawiać wszystko na swoje miejsce.
Wszystko zależy od stopnia skomplikowania naszego projektu. Jeżeli tworzymy prostą stronę internetową prawdopodobnie framework będzie tylko zawracaniem głowy i może nam tylko utrudnić to co jest proste. Jeżeli jednak decydujemy się na bardziej skomplikowany projekt, używanie MVC pozowli wywalić z kodu klas zbędnych HTML (który często zawala miejsce) co sprawi, że kod w metodach stanie się bardziej jasny, przejrzysty i czysty. Poskutkuje to łatwiejszym zrozumieniem tego co robi dana metoda oraz zwiększy czytelność kodu a przez to ułatwi modyfikowanie go ... co tylko się opłaci ! Czytając kod klas skupimy się na tym co klasa robi i co zwraca, a uwolnimy się od zastanawiania się nad tym jak to wyświetla co zdecydowanie pozwoli nam skoncentrować naszą uwagę na rozwiązaniu problemu.
Jeżeli już decydujemy się na skorzystanie z MVC następuje pytanie, czy piszemy własne klasy do obsługi tego co potrzebujemy ponieważ na przykład używamy tylko MVC czy może przydadzą nam się dodatkowe mechanizmy pozwalające na niezależność od rodzaju bazy danych (nie wiemy na czym będziemy pracować), dodatkowe opracowane już przez kogoś mechanizmy czy w końcu niezależność od wersji PHP :)
No comments:
Post a Comment