Jaki framework PHP i dlaczego Zend

Wielu z nas, programistów PHP, siada do komputera i w jedynej słusznej wyszukiwarce wpisuje wyrażenie: „framework php”. Kiedy? Przeważnie jak nam się już kompletnie nudzi. Dlaczego? Po co utrudniać sobie życie?

Po przejrzeniu kilku leadów stron w wyszukiwarce i „po długim i dogłębnym procesie tentegowania w głowie…” trafimy na stronę Zend Framework. Wygląda dość niepozornie. Wiem – sam się na to nabrałem. W kilku zdaniach poniżej postaram się uzasadnić przewrotność tytułu.

Zend Framework – te dwa słowa budzą najczęściej swoisty respekt lub zdziwienie z miną porównywalną do czteronogiego bohatera pewnej popularnej kreskówki. Zend jest nazywany „PHP Company”, i to nie bez powodu. Moim zdaniem Zend Framework to najpotężniejszy framework PHP dostępny na rynku BSD (o ile można o istnieniu takiego rynku mówić). Wśród wielu opinii na jego temat zdecydowanie przeważają pozytywne. Jak już nieraz powtarzałem: każdy obstawia swojego konika.

Jednym z podstawowych założeń każdego frameworka jest stopień swobody pozostawiony nam, programistom. Biblioteki dostarczone w paczce od Zenda są na tyle elastyczne i uniwersalne, że to jak je wykorzystamy zależy tylko od naszej wyobraźni (oczywiście w granicach rozsądku).

Nikt nie narzuca nam jednego, szablonowego sposobu postępowania; chociaż stosowanych jest wiele wzorców projektowych takich jak MVC, Table Data Gateway, Two Step View.

W Zend Framework wybrałem implementację MVC – prawdopodobnie dlatego, że jest najpopularniejsza i najlepiej udokumentowana. W naszym frameworku implementacja MVC złożona jest z 3 głównych komponentów:

● Model – odpowiada za przetwarzanie danych z bazy;

● Controller – odpowiada za obróbkę danych oraz przekazywanie danych do widoku;

● View – odpowiada za wyświetlenie danych w czytelnej i pożądanej formie;

Najprościej rzecz ujmując działa to następująco: Controller pobiera dane z Model i przekazuje do View, który renderuje dynamiczne fragmenty XHTML, HTML lub XML. Należy pamiętać, że Zend Framework jest bardzo elastyczny i każdy z tych składników może być stosowany oddzielnie. Wykorzystywane razem stanowią wspaniałe filary pod budowę naszej aplikacji.

Przedstawię teraz najważniejszy powód, dla którego zdecydowałem się na Zend Framework: abstrakcyjne klasy do obsługi baz danych. Brzmi pewnie dość zabawnie, ale śpieszę z wyjaśnieniem: poważna sprawa, a uśmiech pojawia się kiedy z nich korzystamy – z zadowolenia. Abstrakcyjna obsługa baz danych polega na wskazaniu w pliku konfiguracyjnym adaptera bazy, z którego Zend ma skorzystać. W modelu, niezależnie od wybranego przez nas adaptera, korzystamy z takich samych zapytań dla różnego rodzaju silników bazodanowych. Jedyne, co musimy zrobić, to dziedziczyć po Zend_Db_Table_Abstract. Pomocna rzecz przy redundancji na różnych serwerach, migracjach (odpada nam potrzeba modyfikacji JAKICHKOLWIEK zapytań SQL), etc. Zmieniamy góra 2-3 linijki i nasza aplikacja działa dalej bez konieczności wprowadzania czasochłonnych zmian.

Jak dla mnie bomba. Jeśli dodamy do tego dobre wsparcie wielu IDE oraz dedykowany OPENSOURCE’owy serwer od Zend – czego chcieć więcej?

W artykułach chciałbym pokazać, że nie ma jednej, słusznej drogi i wiele rzeczy można zrobić na swój niepowtarzalny sposób. To co pokażę to mój sposób -> moja droga, lub jak kto woli: #myBestPractice.

Karol Nowicki – Zend Framework Blog

Rozwiązywanie problemów z WebGL

Jeżeli stajesz na głowie, aby uruchomić stronę z WebGL (np. tą http://www.w3center.com.pl/webgl/przyklad/index2.html) a mimo wszystko i tak dostajesz komunikat „Przepraszamy: Nie możemy zainicjować WebGL. Prawdopodobnie używasz nienowoczesnej przeglądarki, nie aktywowałeś WebGL lub masz stare sterowniki w swojej karcie graficznej. Wróć do strony i zajrzyj do artykułu: 'Rozwiązywanie problemów z WebGL'”, w takim razie przeczytaj poniższe instrukcje:

Przede wszystkim aby wykorzystać w pełni możliwości HTML5, czyli m. in. tag <canvas> potrzebujesz przeglądarki, która posiada implementacje WebGL. Jeżeli jeszcze takiej nie masz, lub nie jesteś tego pewny zobacz ten artykuł. Jeśli jednak twoja przeglądarka na 100% posiada implementacje WebGL, a mimo wszystko strony z tą technologią nie chcą się uruchomić, to powinieneś przejrzeć poniższe wskazówki:

Dla użytkowników Mac'ów: Jeżeli WebGL nie chce Ci działać - przykro mi. Nie posiadam żadnych użytecznych rozwiązań problemów jak uruchomić WebGL na Mac'ach, ponieważ nikt nie żalił się na jakieś problemy tego typu, nikt nie zapytał mnie o to i nigdy nie widziałem takich post’ów na forum. Mogę zatem tylko przypuszczać, że wszystko działa podobnie jak na OS X - więc w sumie cały ten akapit jest nie istotny.

Dla użytkowników systemów Windows i Linux: Najczęstszą przyczyną problemów z WebGL (oczywiście oprócz omijania kroków tego poradnika ;-) jest problem ze sterownikiem graficznym. Wszystkie obecne implementacje WebGL w przeglądarkach opierają się na OpenGL (w przyszłości prawdopodobnie się to zmieni), a zatem problem z OpenGL => problem z WebGL. WebGL do poprawnego działania potrzebuje OpenGL w wersji przynajmniej 2.0.

Jeżeli masz grafikę Intela, a WebGL idzie w zaparte i nie chce ruszyć, proszę zostaw komentarz pod tym artykułem a ja postaram się pomóc.

Jeżeli masz grafikę ATI lub Nvidia, pierwszą rzeczą którą powinieneś sprawdzić jest wersja OpenGL zainstalowana na twoim komputerze. Jeżeli masz Windows’a możesz sprawdzić to prosto za pomocą narzędzia GLview. W systemie Linux, należy uruchomić glinfo i znaleźć linię "OpenGl version string". Jeżeli numer wersji jest mniejszy niż 2.0 musisz zaktualizować sterownik graficzny. Najlepiej zrobić to na stronie internetowej producenta, lub skorzystać z Windows Update lub menedżera pakietów w Twojej dystrybucji Linux'a

Jeżeli nawet po zaktualizowaniu sterowników masz ten problem prawdopodobnie Twoja karta graficzna nie wspiera OpenGL (przynajmniej w Twoim systemie). Prywatnie zapytam: Czy będziesz ją trzymał tak długo, aż muzeum techniki zapłaci Ci za nią krocie? Wszystkie nowoczesne karty radzą sobie z tym. Zachęcam zatem do wymiany sprzętu, bo pewnie nowe zakładki w Twojej przeglądarce uruchamiają się z taką prędkością, że aż światło ulega zagięciu (to sarkazm ;-). Jeżeli jednak i to odpada spróbuj skorzystać z renderowania po stronie przeglądarki. Tutaj masz instrukcje dla Windows’a i dla Linux’a.

Powyższy tekst jest luźnym tłumaczeniem angielskojęzycznego kursu WebGL napisanego przez Thomas'a Giles'a, dokonanym z uwagami przez Daniela Miedzika (w3center.pl), za zgodą autora. Oryginał kursu  możecie znaleźć na http://learningwebgl.com. Zachęcam do komentowania.

Kurs webGL - wstęp

Ostatnio coraz więcej mówi się o zastosowaniu canvas w html5. Ten nowy element umożliwia tworzenie elementów dwu i trzy wymiarowych, animowania ich, nadawania im odpowiednich kształtów, tekstur itd. Niebawem flash całkowicie odejdzie do lamusa, sklepy internetowe będą zawierać 3-wymiarowy obraz swoich produktów (nie będący filmem lecz obiektem którym można sterować w dowolną stronę), a Internet będzie miejscem gier 3d w których sterujemy wybraną postacią jak w World of Warcraft. Stety (a może i nie) nie jesteśmy w stanie zatrzymać rozwoju technologii Internetowych. Dlatego zamiast z nimi walczyć - lepiej je dobrze wykorzystać. Poniższy kurs ma za zadanie pomóc zrozumieć podstawy wykorzystania webGL na stronach internetowych i podać przykłady zastosowania ich w systemach Informatycznych.

Cykl 15 lekcji jest luźnym tłumaczeniem z ewentualnymi uwagami tekstu Gilsa. Oryginał można znaleźć tutaj .

Na początku zajmiemy się krótkim opisem przeglądarek, następnie stworzymy statyczny trójkąt i kwadrat (2D), dodamy kolory i gradienty, wprowadzimy je w ruch, stworzymy bryły (3D), nałożymy na nie tekstury, dodamy obsługę klawiatury (up, down, left, right, page up, page down), dodamy cienie i światła, przezroczystość, zajmiemy się wydajnością tworzonych animacji, zaczniemy poruszać kamerą względem obiektów, poruszać obiekty myszą, posmakujemy zaawansowanej obsługi świateł i jej wpływu na wydajność aplikacji, załadujemy obiekty formatu JSON i wiele wiele innych ciekawych rzeczy.

W Polsce bardzo mało mówi się o zastosowaniu webGL. Na pewno po części jest to spowodowane brakiem implementacji tego rozwiązania w standardowych przeglądarkach. Na szczęście - do czasu. Już teraz w wersjach "nocnych" można cieszyć się technologią webGL - a to oznacza, że niedługo przyjdzie "dzień" ;-) Jak skonfigurować swoją przeglądarkę aby korzystała z pełni swoich możliwości? O tym w lekcji nr 0 - już niebawem.

Renderowanie dokumentów w IE, czyli jak używać X-UA-Compatible

Jakiś czas temu tworząc projekt, którym niestety nie mogę się jeszcze pochwalić, natknąłem się na znaczący problem. Portal internetowy o którym mowa tworzony jest w Zend framework'u. Klient jako chętny do popierania wszelkiego rodzaju standardów określił wymaganie dotyczące kompatybilności z przeglądarką FireFox3.5+ i Internet Explorer 8.0+. Oznacza to, że dla Internet Explorer'a 7 nie trzeba tworzyć dodatkowych hacków, plików styli CSS itd. Oby takich klientów było jak najwięcej... ;-)

Przez dłuższy czas projektowane widoki w FF i IE8 wyglądały identycznie. Po jakimś czasie jednak wszystko się posypało. Z minuty na minutę. Nie mogłem dojść do żadnego logicznego wniosku - "Why? Please stand up guy! Stund up?!" Strona po rozsypaniu wyglądała identycznie jak w IE7. Po kilku minutach wykonałem update projektu do aktualnej wersji repozytorium. Sprawdziłem logi. Okazało się, że współpracownik dodał do META tagów definicję X-UA-Compatible.

Czym ona jest? A pamiętacie dlaczego na początku każdego dokumentu HTML, XML, xHTML itd. na początku dodawaliście to:

<doctype html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Powyższy kod definiuje typ dokumentu np. xHTML. W praktyce jest on często wykorzystywany do wskazania dla przeglądarki Internet Explorer, w jaki sposób ma odczytywać wszelkie tagi i style. Gdy przestawialiśmy się z IE5 na 6 wersje, następnie 7, od roku na 8 za każdym razem twórcy Internet Explorera zbliżali się powolnymi krokami do standardów określanych przez w3c. Niestety ich upartość (której ze względów finansowych wcale się nie dziwie) pozwalała na wsteczną kompatybilność.

Wracając do X-UA-Compatible. Ten Meta tag był ustawiony na emulowanie strony jako IE7 (EmulateIE7) - stąd zepsuty wygląd. Wtedy pozostały 2 wyjścia - albo usunę ten tag, albo ustawie go w sposób prawidłowy. Niestety polskie dokumentacje nie rozpisały się nad tym zbyt wiele. W Internecie można było znaleźć informacje tylko o stworzeniu takiej opcji, o jej dostępności w IE8 i o tym co wpisać jako wartość by włączyć emulacje jako IE7. Tylko po co mi wiedzieć jak popierać brudy Microsoftu? Na szczęście po kilku minutach szukania i na oficjalnym blogu Internet Explorer'a znalazłem potrzebną informacje. Tam znajdziecie całkowity opis możliwości. Ja skupię się na jedynych słusznych wyborach ;-)

W artykule z 16 czerwca 2010 o intrygującym tytule "IE’s Compatibility Features for Site Developers" można napotkać się na informacje o tym jak wymuszać kompatybilność nawet z 9 wersją IE. Żeby to uczynić wystarczy, wpisać:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9">

lub

<meta http-equiv="X-UA-Compatible" content="IE=9">

Podobnie, jeżeli Twoja strona ma być kompatybilna z IE8 wystarczy w miejsce "9" wpisać "8". Proste? Tylko po co to robić? Ktoś mądry wpadł na pomysł, aby narzucić renderowanie strony zawsze w najnowszej dostępnej wersji. Aby takie rozwiązanie wdrożyć do swojej strony wpiszcie:

<meta http-equiv="X-UA-Compatible" content="IE=edge">

Do tego ostatniego rozwiązania wszystkich zachęcam. Tak długo dopóki projektanci Internet Explorera będą szli w kierunku akceptacji standardów w3c - tak też długo ta opcja będzie najlepszą z możliwych.

Jeżeli uważasz, że kilka bitów kodu zaśmieci Twój kod, pomyśl o jeszcze jednej przewadze takiego rozwiązania. Twój klient, nie kliknie przypadkiem na włączenie trybu (nie)zgodności z wcześniejszymi przeglądarkami. Nie zadzwoni któregoś pięknego słonecznego popołudnia z twierdzeniem, że mu lub jego klientom strona się popsuła. Im klient mniej się denerwuje - tym lepiej dla Ciebie... Po uzupełnieniu X-UA-Compatible zniknie poniższy przycisk:

Aha... pamiętajcie jeszcze, że ustawienie X-UA-Compatible ignoruje Doctype dokumentu. Warto to uwzględnić, żeby przypadkiem nie stworzyć przeczącemu sobie kodu.

Preludium

World wide web, potocznie nazywana siecią www istnieje już ładnych parę lat (przez parę lat obeznany czytelnik - do którego kierowana jest strona - powinien rozumieć koniec lat 80-tych XX wieku). Na początku powoli rozwijająca się sieć, której zalążek sięga historii brytyjskiego inżyniera i naukowca sir Tima Berners-Lee, przerosła się w ogromną strukturę będącą podstawą kolejnego stulecia. Każda z kolejnych norm i wszelkiego rodzaju standardów prędzej czy później przeżywały już kilkakrotne odsyłanie do lamusa. Nikt z początku chyba nawet nie wyobrażał sobie zasięgu korzyści jaki przyniesie Internet.

Wraz z upływem czasu, ta tkana przez ludzi “sieć” zaczęła przybierać na rozmiarach do tego stopnia, że niezbędne okazało się stworzenie wyszukiwarek internetowych. Google - światowy lider w tej dziedzinie - za swoją misję uznał skatalogowanie światowych zasobów informacji i uczynienie ich powszechnie dostępnymi i użytecznymi

Pewnie gdyby nie ludzie, którzy znaleźli w tym sposób na łatwy zarobek, wszystko układało by się pięknie. Niestety… choć miało być dobrze - wyszło jak zawsze… Pozycjonowanie stron (często siłowe) zbombardowało bazy naszego “ojca” Larrego Paga. Dziś co raz to trudniej znaleźć proste odpowiedzi na wszelkiego rodzaju pytania. Kiedy zrozumieją to wszyscy użytkownicy Internetu? Na to pytanie nie jestem w stanie odpowiedzieć.

Wiem jednak, że dobre produkty trzeba promować. W obowiązku osób tworzących największą sieć połączeń elektronicznych jest stosowanie się do najnowszych standardów. Na pewno zauważyłeś powiązania w nazwie strony na której teraz jesteś z organizacją w3c - World Wide Web Consortium. Nie ukończone do tej pory wskazówki interpretowania przez przeglądarki internetowe, zostały już w znaczącej mierze wykorzystane. To dobry znak, zachęcający by nie czekać z wdrożeniem standardów zanim pojawią się ich ostateczne wersje.

HTML5, CSS3, biblioteki JS - nazwy te związane z kodem po stronie klienta nie są nam już obce. Jak jednak zastosować je w praktyce? Dlaczego w ogóle to robić? PHP, .NET - również serwerowe technologie idą wciąż do przodu. Co raz to słyszymy o nowej wersji znanego frameworka itd.

Blog, którego właśnie czytasz jako swój główny priorytet uznaje traktowanie o standardach internetowych i ich praktycznym zastosowaniu.

Ścieg tych patetycznych bzdur wypisanych prawie o 2 w nocy będzie musiał niestety stanowić preludium do bloga w3center. Kolejne posty - już niebawem. Zapraszam.