Reklamy

Tak, google zarabia na reklamach i nie są to przychody małe, zastanowicie się dlaczego inne serwisy nie mają takiej fortuny z tego rodzaju świadczeń? Odpowiedz jest bardzo prosta google monitoruje naszą obecność w sieci. Na podstawie wszystkich zapytań, stron na których przebywaliśmy i ilości czasu spędzonego na nich, generuje  profil każdego z nas, a następnie dokleja nam do strony którą odwiedzamy dedykowane reklamy. Może i nie jest to zbyt wielkie odkrycie, ale analizując i przekładając na nasze potrzeby (tworzenia stron www) możemy go wykorzystać by zainteresować użytkownika wpisami które go na prawdę interesują i które będą od razu wpadać mu w oko bez konieczności wertowania dużej ilości podstron wpisów.

Tematem głównym wpisu

… nie będzie google, ani jego niepodważalna fortuna, a właśnie sposób na wykonanie takiego gadżetu na naszą stronę. Na samym początku trzeba wybrać drogę jaką pójdziemy. Możliwości jest dosyć sporo od reguł pisanych dla wszystkich użytkowników, nawet tych nie zalogowanych – tutaj opierając się na ip lub ciasteczkach tak jak robi to google do systemu tylko dla zalogowanych użytkowników. Odpowiedzią w którą stronę powinniśmy pójść jest odpowiedz na pytanie:

Instalując taki moduł mamy zamiar zarabiać na użytkownikach czy ułatwić im życie?

Osobiście chcę zainteresować użytkownika treścią mu potrzebną, więc zainwestuję w mniej skomplikowany system, ale bardziej precyzujący interesujące użytkownika artykuły. Dzięki temu nie tworząc masy profili osób, które nie powrócą do mnie na bloga lub osób których identyfikacja nie jest możliwa. O samym rozpoznawaniu użytkowników można by napisać obszerną notkę więc tutaj powiem tylko o użytkownikach najłatwiej rozpoznawalnych – stałe ip lub konta w naszym serwisie i ich przeciwieństwie – osoby nie akceptujące ciastek, nie posiadające stałego ip. Dla osób zainteresowanych tematem identyfikacji użytkowników nie posiadających konta w naszym serwisie podsunę pomysł – rozpoznawał bym ich na podstawie adresu ip i ciasteczek z wielkim naciskiem na to pierwsze, ciasteczka są znane z swej ulotności, a osoby z stałym ip będą mieć komfort – oczywiście o poprawności tego rozwiązania można by dużo złego powiedzieć, kiedyś coś o tym napiszę!

Kolejnym gorszym problemem jest określenie praw na jakich będziemy przypisywać do konkretnych użytkowników interesujące ich wpisy. Mamy kilka dróg: od bardzo restrykcyjnych i dających sporą dokładność zarazem mocno obciążających nasze serwery jak i sposoby dla leniwych, przedstawię oba i krótko omówię w jaki sposób można by to zorganizować za pomocą mysql’a.

Tagi

Mówimy o gruszce, a tutaj znienacka pietruszka – już śpieszę z wyjaśnieniami, do zrozumienia całości tematu przyda nam się wiedza o tz. tagach – są to krótkie zwięzłe tytuły którymi możemy określić zawartość danego wpisu, jednoznacznie opisujące jego zawartość zazwyczaj służą do pogrupowania treści niczym kategorie tylko w nieco bogatszy sposób. Wpis zazwyczaj posiada jedną kategorię i co najwyżej pod kategorię, używanie kilku kategorii do opisu danej treści jest raczej czymś nie spotykanym, a tagi są właśnie takim elementem który się genialnie do tego nadaje!

Leniwe doradzanie treści

Leniwe ma oznaczać takie które zasobów naszego serwera nie pożre razem z dziesięcioma użytkownikami online, więc zastanawiamy się jak można podejść gościa by wyzyskać od niego informację o jego zainteresowaniach, nie pytając się go w prost. Możliwość jest tylko jedna – musimy go po cichu śledzić i spisywać wszystkie adresy na jakich bywa w obrębie naszej witryny. Tutaj przydadzą nam się informacje o tagach, opis powyżej staje się potrzebny każdy wpis ma kilka tagów więc zakładając użytkownika czytającego wpis o Zend z dwudziestoma tagami, możemy insynuować że jest zainteresowany nim, a opisem zawartości artykułu czy też wpisu są tagi, użytkownik więc dostaje dopisek do swojego konta o zainteresowaniu danymi tagami, a jeśli takie tagi pojawiły się już w jego profilu ich siła zostaje zwiększona.

Teraz czas na analizę informacji posiadanych o preferencjach, oczywistym jest że tagi z największą siłą są najbardziej lubiane przez danego gościa więc trzeba znaleźć wszystkie wpisy zawierające je i porównać ich siłę – w końcu wpis może posiadać kilka tagów więc tutaj przyjdzie z pomocą jakiś bardziej zaawansowany algorytm porównawczy (następnym razem o nim), teraz wypadało by tylko nie podawać artykułów już przeczytanych przez użytkownika, w końcu nie chcemy podsuwać komuś artykułu który właśnie czyta!

Dokładny doradca

Tutaj skupię się tylko na elementach które wzbogacą nasz leniwy system. Pierwszym takim elementem są kategorie, precyzyjność ich jest za razem plusem jak i minusem w takiej aplikacji, z jednej strony jasno mówią co takiego czyta użytkownik, ale i ograniczają nas tylko do jednej kategorii – jest to element pośredni tak na prawdę pomiędzy naszym leniwym a dokładnym pomagierem.

Kolejną metodą jest śledzenie czasu spędzonego nad danymi tagami. Notujemy nie ilość wystąpień danego tagu a czas jaki użytkownik spędził nad artykułami w jakich występuje. Jest to rozwiązanie dość pracochłonne i obciążające server, jednak o wiele bardziej precyzyjne, a to jeszcze nie szczyt jego możliwości. Przy porównywaniu można brać pod uwagę nie tylko ilość czasu spędzonego nad danym tagiem, a również obszerność artykułu, wiadomo, że dwa, trzy krótkie wpisy mogą bardziej interesować użytkownika niż jeden na prawdę „otyły” i zmuszający do dłuższego zaczepienia na nim oka.

Rozwiązanie techniczne

Nie jest to nic trudnego, w jednej tabeli mamy zapisane tagi w innej użytkowników teraz trzeba dodać kolejną z idTag, idUser i siłą która będzie reprezentowana przez jeden z sposobów opisanych powyżej, poza tym przyda się lista przeczytanych wpisów dla każdego z użytkowników.

Plusy płynące z takiego systemu

Nie dość, że pomagamy użytkownikom w wyborze treści do przeczytania to tworzymy tym samym dość dokładne statystyki mówiące o zainteresowaniu naszych odbiorców, od teraz będziemy wiedzieć które wpisy powinny być częściej wydawane.

Podsumowanie

Warto wspomnieć o plusach i minusach takiego rozwiązanie, na małą skalę może i nie istotnych – jednak pamiętajmy że takie rozwiązania zazwyczaj są używane na dużą skalę, a ich dokładność rośnie z czasem! Tak na prawdę jeśli będziemy dysponować ogromną bazą wpisów to będziemy wpływać pod świadomie na kształtowanie gustu czytelnika,. Mimo, że wybór podjął niby samodzielnie to my decydujemy o przypisanych frazach i możemy to robić błędnie, tym samym zmniejszając indywidualność czytelników, firma google jest idealnym przykładem takich zagrań – nasza indywidualność jest zminimalizowana i tak na prawdę wpasowujemy się do jakiejś danej grupy niż reprezentujemy sami siebie.

Wpis oparty główne na moich przemyśleniach, ładnie reprezentuje zabiegi google’a, yod wielu lat na nas testuje zarabiając krocie, takie zachowanie ma zgubny wpływ na nasz rozwój, ale przyczynia się też do szybszego znalezienia informacji, a także zdejmuje z nas obowiązek płacenia z usług takich jak google, youtube i gmail.

Od czasu do czasu pomiędzy obszernymi wpisami będą się pojawiać tz. mini wpisy których treść nie nadaje się na cały wpis, a informacje w nich zawarte są dość użyteczne i nie chciał bym ich wykładać poza kurs. Ten wpis będzie pierwszym takim mini wpisem, w tytule będę podawać pomiędzy jakimi wpisami został opublikowany z racji na inną numerację.

Konfiguracja wyświetlania błędów w Zend Framework

Miejscem w jakim ustalamy czy Zend ma nas informować o szczegółach błędów jest plik .htaccess w katalogu public każdego projektu, jego standardwa zawartość to:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ – [NC,L]
RewriteRule ^.*$ index.php [NC,L]

Jak widać są to zwykłe regułki .htaccess, przed nimi mamy pustą linię wpisując w niej:

SetEnv APPLICATION_ENV development

Mówimy naszej aplikacji, że pracujemy w trybie deweloperskim dzięki czemu wyświetlanie błędów zostanie uruchomione, aplikacja posiada również inne tryby w jakich może pracować, wszystko jest opisane w plikach konfiguracyjnych, podam przykład by wyjaśnić na czym to polega, plik z projketu użytego w ostatniej części kursu (#03):

H:\zf\application\configs\application.ini

I jego zawartość:

[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH „/../library”
bootstrap.path = APPLICATION_PATH „/Bootstrap.php”
bootstrap.class = „Bootstrap”
appnamespace = „Application”
resources.frontController.controllerDirectory = APPLICATION_PATH „/controllers”
resources.frontController.params.displayExceptions = 0

[staging : production]

[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.frontController.params.displayExceptions = 1

Jak widać całość jest podzielona na 4 części za pośrednictwem tekstu w nawiasach, są to typy konfiguracji, a o aktywnie używanym decyduje właśnie linia z pliku .htaccess którą przytoczyłem wcześniej. Jeśli w owym pliku zabraknie deklaracji konfiguracji zostanie użyta [production] która odpowiada za aplikację środowisku produkcyjnym czyli ostatecznym.

Jak widać każda inna konfiguracja dziedziczy po [production], dowiadujemy się o tym poprzez znak dwukropka, całość możemy zapisać bez niego jednak wymagane będzie powtórzenie wszystkich deklaracji, a to mija się z celem. Więc zadeklarowanie:

SetEnv APPLICATION_ENV development

Uruchomi konfigurację [development : production] dziedziczącą po [production], a jak widzimy w [development : production] mamy zapisy mówiące o wyświetlaniu błędów, przez parser php jak i przez wyjątki samego framework’a.

Przykład błędy Zend Framework

Pokażę przykładowy błąd jaki wygeneruje nam aplikacja  w przypadku braku akcji index kontrolera index, wygląda on następująco:

An error occurred

Page not found

Exception information:

Message: Action „index” does not exist and was not trapped in __call()

Stack trace:

#0 B:\ZendServer\share\ZendFramework\library\Zend\Controller\Action.php(518): Zend_Controller_Action->__call('indexAction', Array)
#1 B:\ZendServer\share\ZendFramework\library\Zend\Controller\Dispatcher\Standard.php(295): Zend_Controller_Action->dispatch('indexAction')
#2 B:\ZendServer\share\ZendFramework\library\Zend\Controller\Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#3 B:\ZendServer\share\ZendFramework\library\Zend\Application\Bootstrap\Bootstrap.php(97): Zend_Controller_Front->dispatch()
#4 B:\ZendServer\share\ZendFramework\library\Zend\Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()
#5 H:\zf\public\index.php(26): Zend_Application->run()
#6 {main}

Request Parameters:

array (
  'controller' => 'index',
  'action' => 'index',
  'module' => 'default',
)

Jak widać w wyraźny sposób mówi nam o braku akcji index, dodatkowo na samym końcu zaznacza jaka akcja jest wywoływana, z którego kontrolera i modułu, więcej do szczęścia nie trzeba.

Podsumowanie

Podczas pisania kodu człowiek popełnia błędy i jest to normalna sprawa by ułatwić ich odnajdywanie trzeba wyświetlić dodatkowe informacje o błędach dzięki temu wpisowi każdy z Was wie jak to zrobić – miłego korzystania!

W tym wpisie dowiemy się jak dodawać i usuwać kontrolery i akcje dwoma sposobami „ręcznie” i za pomocą pliku zf.bat, zabieramy się do roboty bez zbędnego gadania.

Tworzymy aplikację testową

Dlaczego kolejną? Nie chcę by kolejne zmiany były wprowadzane na jednym projekcie spowodowało by to zamieszanie więc za każdym razem będziemy tworzyć nowy projekt najlepiej w czystym katalogu www, czyli wypadało by przenieść jego zawartość do innego miejsca tak by nie pomieszać wszystkiego i mieć do czego wrócić w razie niepewności.

Ostatni wpis nadał tak na prawdę całemu kursowi pewien schemat katalogów idę za obietnicą i będę się go trzymać!

W roli przypomnienia dodam, że mój server jest skonfigurowany w następujący sposób, katalog www/public jest głównym katalogiem servera, nowy projekt tworzę w pustym katalogu www, a katalog public jest generowany przy tworzeniu nowego projektu.

Odpalamy cmd, wchodzimy do katalogu www (chyba, że wedle mojej rady mamy plik do odpalania cmd – wtedy mamy jedną komendę z głowy), tworzymy nowy projekt używając znanej nam już komendy z małą zmianą:

zf create project . ZF#o3

Tak komenda tak jak i jej pierwowzór stworzy nam nowy projekt, a od poprzedniczki różni się tylko lokalizacją w jakim zostanie umieszczony, mianowicie nowy projekt pojawi się w katalogu aktualnie wybranym, dzięki czemu efekty stworzenia nowego projektu możemy podziwiać od razu pod adresem lokalnej maszyny w moim przypadku zf.server.

Tworzenie kontrolerów

Nasza aplikacja jak wiecie z poprzedniej części już na strat posiada dwa kontrolery:

• index
• error

A w niech odpowiednie akcje, teraz zajmiemy się stworzeniem nowego kontrolera tak by dołączył do tej dwójki, są na to dwa sposoby przedstawione poniżej.

zf.bat

By stworzyć nowy kontroler za pomocą pliku zf.bat musimy odpalić cmd i wejść do katalogu projektu, w tym przypadku jest to katalog www i znów przydaje się nasza magia – korzystając z pliku index.bat i stosując kropkę od razu jesteśmy w dobrym miejscu. Tak by operacje na naszym projekcie za pomocą zf.bat powiodły się plik .zfproject.xml powinien znajdować się w głównym folderze aplikacji, zawiera on informacje o projekcie i jest wymagany.

Gdy jesteśmy już w katalogu głównym aplikacji wpisujemy:

zf create controller nowyKontroler

Jeśli wszystko przebiegło pomyślnie powinniśmy zobaczyć komunikat o stworzeniu nowego kontrolera i zaktualizowaniu pliku zfproject.xml. Możemy sprawdzić efekty naszych działań wchodząc pod adres:

http://zf.server/nowy-kontroler

Jak widzicie każda duża litera została zamieniona na małą i poprzedzona myślnikiem, taki zapis jest charakterystyczny do linków i plików widoku, w innych miejscach posługujemy się normalną nazwą kontrolera. Wynikiem powyższego kodu jest:

W tym wpisie chcę pokazać jak skonfigurować server www na nasze potrzeby, pokażę jakiej konfiguracji używam i będę się starał w następnych wpisach trzymać się  tej konwencji. Do tego wpisu przekonało mnie zamieszanie jakie tworzy się wśród moich wpisów związane z katalogami i konfiguracją servera – nie chcę by to była przeszkoda w zrozumieniu kursu.

Układ plików

Jako że jestem osobą, aż za bardzo poukładaną to nie mogło by być inaczej gdyby server też nie był zainstalowany dokładnie wedle moich upodobań. Na dysku B:/ zainstaluję server, a katalogiem głównym będzie dysk H:/ dlaczego tak? Pliki z katalogu głównego potrzebują częstego backup’u i są bardzo często używane więc oddzielny dysk jest moim zdaniem idealny, wiem czym są skróty, ale taki układ osobiście mi odpowiada, nic jednak nie stoi na przeszkodzie by w miejscu w którym podaje ścieżkę na dysku dodać inną do własnego katalogu.

Jakie oprogramowanie wybrać

Na rynku jest cała masa oprogramowania jakie można zastosować nie zmuszając się do instalacji wszystkich komponentów od zera, jak że mój komputer jest tylko i wyłącznie środowiskiem dla mnie i nikt inny nie ma do niego dostępu, a ja sam nie wymagam by server był wysoce konfigurowalny „z pod okienka” to wybrałem produkt Zend’a, aczkolwiek kiedyś korzystałem z wielkim zadowoleniem z webserv niestety projekt upadł, a paczki są strasznie przestarzałe. Środowisko otwarte na świat mam na pc przeznaczonym do tego celu i oparte na ręcznej instalacji – kiedyś może powiem coś na ten temat.

Inne dostępne na rynku:

• Webserv – http://webserv.pl
• Krasnal – http://www.olesno.pl/~pablo/krasnal/
• Xamp – http://www.apachefriends.org/en/xampp.html
• Wamp – http://www.wampserver.com/
• Zend – http://framework.zend.com/
• EasyPHP – http://www.easyphp.org/

Kilka mi znanych rozwiązań, różnie bywa z aktualnością powyższych, ale wybór jest dość spory i trzeba go przemyśleć, szkoda pracy do przeinstalowywania całości.

Pobieramy i instalujemy wybraną paczkę

Osobiście wybrałem Zend’a, pobrać można go tutaj, wybrałem wersję Zend Server Community Edition jako, że zapewnia podstawowe funkcje i jest darmowa, tutaj trzeba zaznaczyć, że inne paczki mogą posiadać konfigurację w opcjach i zmiana niektórych wartości ręcznie może, ale nie musi zakłócić ich działania nie mniej jednak każda powinna podać się takim zabiegom.

Wybieram paczkę z php 5.3 logujemy się lub gdy nie posiadamy konta tworzymy je, jest wymagane do pobrania plików, a administratorzy nie są ludźmi bezczelnymi i nie uświadczmy spamu z ich strony.

Instalacja samego oprogramowania jest bardzo prosta i w zasadzie polega na czekaniu i klikaniu dalej, jedyne co przyjdzie nam wybrać to wersja i ścieżka, ja z racji upodobań i podziału systemu umieszczam całość wprost na czystym dysku B:/ przeznaczonym tylko do tego celu. Po zainstalowaniu zostanie odpalona przeglądarka i krótka trzy etapowa konfiguracja, polegająca na zatwierdzeniu regulaminu i podaniu hasła do servera, trudne – nie! Od teraz posiadamy wstępnie skonfigurowany serwer.

Server jest w wersji ograniczonej każdy może wypróbować pełną wersję trzeba tylko kliknąć jeden z napisów „Wypróbuj za darmo” w panelu, dostaniemy kod ważny 30 dni – może komuś się spodoba i będzie miał za dużo $$, produkt kosztuje kilka tysięcy $, komercyjnie i osobiście zostanę na darmowym apache!

Konfiguracja

Server sam w sobie już działa i na dobrą sprawę mógł by już pozostać w tej postaci, ale by  żyło nam się lepiej wymaga kosmetycznych zmian w plikach. Zabierajmy się do roboty postaram się napisać co i poco modyfikuje.

Zmiana katalogu głównego

Katalog główny w podkatalogu servera nie odpowiada mi osobiście i to bardzo, skróty niby istnieją, ale dla bezpieczeństwa wolę przenieść całość na inny dysk. Nie jest to trudne jak wie się gdzie szukać.

Poszukujemy pliku httpd.conf u mnie znajduje się on w B:\Apache2\conf\httpd.conf i przechodzimy do jego edycji, ogólnie plik odpowiada za konfigurację servera apache, dodawania modułów i ich wstępną konfigurację.

Odnajdujemy linię:

DocumentRoot ”B:\Apache2″

Katalog można zmienić dowolnie, ja wedle wstępnych ustawień zmieniam na H: i zostawiam ten kawałek w takiej formie:

DocumentRoot ”H:”

Zaznaczam brak \ jest to dość ważna kwestia więc warto pamiętać o tym by nie szukać usterki.

Teraz szukamy:

<Directory „B:\Apache2/htdocs”>
…
</Directory>

Jest to konfiguracja katalogu, który jeszcze chwilę temu był katalogiem głównym aplikacji – zmieniamy na nasz katalog, znów u mnie będzie to wyglądać tak:

<Directory „H:”>
…
</Directory>

Teraz w magicznym pliku hosts systemu windows wykonamy przekierowanie, plik znajdziemy C:\Windows\System32\drivers\etc na systemie win7, w nim można dodać przekierowanie w obrębie lokalnej maszyny, tak by wpisując np. localhost2 być przekierowywanym do 127.0.0.2 itd.. Konstrukcja komendy wyglądać powinna tak:

miejsce_gdzie_przekierowujemy link_który_wpisujemy

Dla naszych potrzeb podajemy:

127.0.0.1        server
127.0.0.1        temp.server
127.0.0.1        www.temp.server

Jeśli chcemy mieć możliwość dostępu do kilku projektów bezpośrednio z domeny bez używania katalogów musimy tutaj dla każdego z nich popełnić taki wpis. W powyższym wpisie udostępniłem nazwę server i temp.server przekierowując je na lokalny server.

Teraz po zapisaniu pliku hosts i restarcie servera wpisując w przeglądarkę server lub temp.server otrzymamy dostęp do dysku H lub innego w zależności od wcześniejszego wyboru, oczywiście localhost też funkcjonuje i też wskazuje ten katalog.

Teraz trzeba jakoś rozróżnić wybór naszej subdomeny i na tej podstawie wybrać katalog, jest wiele sposobów które potrafią zautomatyzować cały proces, ale to temat na cały wpis, a nie na jego fragment więc przedstawię najprostszy ręczny sposób. Dla osób chcących coś extra kilka słów kluczowych. Serwer dns i wildcard – brak potrzeby wpisywania domen do hosts do tego moduł do apache mod_vhost_alias i w sumie tyle.

Do rozróżnienia subdomen posłużymy się tz. wirtualnymi hostami, znów odpalamy httpd.conf i szukamy lini:

# Virtual hosts
#Include conf/extra/httpd-vhosts.conf

Musimy usunąć znak # w ten sposób linia będzie brana pod uwagę podczas startu apache, powinny wyglądać tak:

# Virtual hosts
Include conf/extra/httpd-vhosts.conf

Zapisujemy i przechodzimy do pliku conf/extra/httpd-vhosts.conf jak się domyślacie w nim będziemy zapisywać konfigurację wirtualnych hostów, mogli byśmy to zrobić w pliku konfiguracyjnym apache, ale w ten sposób nie pomieszamy sobie całej konfiguracji, a i w przyszłości będzie nam lepiej nad całością panować.

Tutaj nie za komentowaną (linie poprzedzone znakiem #) część usuwamy i dodajemy:

<VirtualHost *:80>
DocumentRoot „H:\temp/public”
ServerName temp.server
ServerAlias www.temp.server
</VirtualHost>

Kopiując taki wpis i zmieniając DocumentRoot, ServerName i ServerAlias na inne możemy stworzyć dowolną ilość subdomen, osobiście mam udostępniony cały katalog domowy i dwie subdomeny: temp – na aktualny projekt i cmssspl – do ciągłej pracy nad własnym projektem.

Na potrzeby tego kursu dodaję kolejną zf.server, by tego dokonać trzeba dodać dwa wpisy w hosts:

127.0.0.1        zf.server
127.0.0.1        www.zf.server

Przechodzimy do httpd-vhosts.conf i dodajemy kolejnego wirtualnego hosta w taki sposób:

<VirtualHost *:80>
DocumentRoot „H:\zf/public”
ServerName zf.server
ServerAlias www.zf.server
</VirtualHost>

Teraz wystarczy stworzyć tylko katalog H:\zf/public i sprawdzić czy wszystko działa tak jak powinno, w tym celu restartujemy server i wpisujemy w przeglądarkę:

http://temp.server

Jeśli wszystko działa powinniśmy zobaczyć zawartość:

H:\zf\public

Koniec od teraz możemy się cieszyć nowymi subdomenami.

Pliki .htaccess

Są to pliki konfiguracyjne działające w obrębie jednego katalogu, standardowo są wyłączone a mogą zdziałać cuda np. przyjazne linki, Zend standardowo korzysta właśnie z takich linków więc normą jest ich włączenie – dziwne, że standardowo postanowiono je wyłączyć.

Jak zwykle wchodzimy do pliku hosts i szukamy ponownie:

<Directory „H:”>
…
</Directory>

Linia może wyglądać nieco inaczej, już edytowaliśmy ten fragment konfiguracji, tym razem w obrębie tych znaczników szukamy:

AllowOverride None

Zamieniamy na:

AllowOverride All

Teraz szukamy:

<Directory />
Options FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
</Directory>

I znów w tym kawałku zamieniamy AllowOverride None na AllowOverride All. Zmienna odpowiada za udostępnieni nadpisywania konfiguracji poprzez pliki .htaccess, czyli właściwie odpowiada za umożliwienie używania tych plików, teraz możemy się już cieszyć urokami .htaccess.

Wyświetlanie błędów

Standardowo server ukrywa informacje o błędach by osoby przypadkowe osoby przeglądające nasz serwis nie dostawały szczegółowych opisów „co z naszą aplikacją jest nie tak”, takie działanie w naszym wypadku jest nie na miejscu w końcu chcemy mieć ułatwioną pracę i widzieć błędy.

Musimy odnaleźć plik konfiguracyjny php, nazywa się php.ini i w moim przypadku znajduje się w:

B:\ZendServer\etc\php.ini

W pliku tym musimy odnaleźć dwa fragmenty:

error_reporting  =  E_ALL

I dopilnować by był właśnie w tej postaci, a inne error_reporting  =  * były poprzedzone znacznikiem komentarza, w tym przypadku jest to ;, teraz szukamy:

display_errors = Off

I zamieniamy na:

display_errors = On

Od tej pory nasza aplikacja będzie nam na bieżąco wyświetlać wszystkie błędy, nawet te najdrobniejsze.

Wyjaśnień słów kilka

Od teraz katalogiem głównym aplikacji w tym kursie będzie:

H:\zf\public

A subdomeną którą będę się posługiwać:

http://zf.server/

Dla osób chcących tak jak ja ułatwić sobie pracę i za każdym razem nie musieć w cmd wchodzić do katalogu servera mogą zastosować taki mały trik, w katalogu H:\zftworzymy plik zend.bat a w jego treści:

cmd
pause

Od teraz odpalając ten plik będziemy od razu w głównym katalogu naszej aplikacji, tym samym zaoszczędzamy nasz czas.

Podsumowanie

Mam nadzieję, że każdemu udało się skonfigurować serwer wedle własnych upodobań bez większych kłopotów, mam też nadzieję, że nie pominąłem czegoś istotnego starałem się by nie było żadnych braków, jeśli macie jakieś pytania piszcie – postaram się pomóc!

Odpalimy naszą pierwszą aplikację i na jej podstawie powiem coś o strukturze katalogów, plikach i kodzie w nich zawartym – same podstawowe informacje o funkcjonowaniu Zenda. Na ich podstawie każdy powinien umieć uruchomić swoją pierwszą stronę opartą o Zend.

 Pobieramy Framweork

Pierwszą czynnością jaką musimy wykonać jest pobranie samego frameworka, możemy pobrać go tutaj, klikamy na wielki napis „Download New” i pobieramy interesującą nas paczkę, do wyboru mamy sam fw jak i z serverem lub dokumentacją. Jeśli nie chcemy żadnych dodatków klikamy na Zip lub tar.gz obok „Zend Framework 1.11.11 Minimal”, wersja oczywiście może się różnić od tej opisywanej tutaj.

Co dalej?

W paczce znajdziemy kilka folderów i plików, najważniejszym jest katalog library zawiera on wszystkie biblioteki Zend’a i na dobrą sprawę wystarczył by nam do wszystkiego, ale po co utrudniać sobie życie? Wrócimy do niego w dalszej części, katalog bin zawiera plik zf.bat dzięki niemu możemy wykonywać pewne operacje na naszej aplikacji nie odpalając naszego ide. Proponuję całą zawartość katalogu bin wrzucić do C:\Windows dzięki czemu korzystając w przyszłości z niego nie będziemy zmuszeni podawać całej ścieżki do pliku a tylko nazwę pliku zf.

Server

Jak pewnie wiecie (a jeśli nie, to czas przeczytać pierwszy wpis) aplikacje php potrzebują servera, tutaj jest kilka możliwości:

• Server w sieci
• Server na naszym Pc
• Gotowe rozwiązanie
• Ręczna instalacja

Osobiście polecam w etapie produkcyjnym rozwiązanie drugie, nie jest istotne czy zainstalujecie całą paczkę ręcznie czy użyjecie jakiejś gotowej. Jeśli nie masz jeszcze servera powinieneś się w niego zaopatrzyć. W dalszym etapie będę opisywać poczynania na maszynie lokalnej – tak jest wygodniej i oszczędzamy na opóźnieniach ftp.

Gdy mamy już server

Otwieramy konsolę cmd, standardowo znajdujemy się C:\User\nazwa_użytkownika używając komendy cd .. wychodzimy katalog do góry, a wpisując ścieżkę cd C:\Users\nazwa_użytkownika\Desktop dostaniemy się na pulpit (Windows 7) dla xp będzie to inna ścieżka – krótkie przypomnienie dla osób nie korzystających na codzie z konsoli.

Teraz możemy stworzyć nasz pierwszy projekt, wydajemy polecenie zf create project nazwa_projektu, jeśli wcześniej nie wkleiłeś pliku zf.bat do katalogu C:/Windows musisz podać pełną ścieżkę do pliku zf.bat np. C:/katalog/zf create project nazwa_projektu lub wejść do niego za pomocą komendy cd.

W oknie cmd powinniśmy dostać komunikat z ścieżką do nowo stworzonego projektu w moim przypadku jest to C:\Users\nazwa_użytkownika\Desktop\nazwa_projektu. Najlepiej wykonywać te operacje od razu w katalogu www naszego servera tym samym zaoszczędzimy sobie przenoszenia plików.

Co zawiera magiczny katalog nazwa_projektu

Zawartość katalogu nazwa_projektu powinna wyglądać tak:

Krótkie opisy poszczególnych katalogów i plików:

• application – zawiera naszą aplikację
• configs – jak sama nazwa mówi, katalog w którym znajdują się pliki konfiguracyjne całej aplikcji
• application.ini – główny plik konfiguracyjny aplikacji
• controllers – tutaj znajdują się kontrolery, każdy plik to jeden kontroler
• models – modele aplikacji
• views – miejsce na widoki aplikacji
• helpers - pomocnicy widoku
• scripts – główne pliki widoku
• Bootstrap.php - miejsce wstępnej konfiguracji i naszego kodu, plik jest wykonywany na wstępie naszej aplikacji
• docs – dokumentacja projektu (nie interesuje nas)
• library – pusty katalog do którego należy wkleić pobrany wcześniej katalog o takiej samej nazwie zawierają biblioteki
• pubpic – główny katalog servera www
• test – testy naszej aplikacji (nie interesuje nas)
• plik .zfproject.xml – plik wykorzystywanie przez zf.bat przechowuję strukturę naszej aplikacji (nie interesuje nas)

Pliki oznaczone jako (nie interesuje nas) zostawiamy w spokoju, na tym etapie nie są nam potrzebne wiec jeśli ktoś ma kaprys by pozbyć się nie potrzebnych elementów to śmiało może usunąć je.

Konwencja MVC

Część z Was pewnie jest ciekawa czym są magiczne kontrolery, widoki i modele – więc śpieszę z wyjaśnieniem.

Zf jest oparty na MVC, co to znaczy? MVC jest jednym z wielu wzorców programowania, ostatnimi czasy stał się bardzo modny zawdzięcza to jasnym podziałom między trzema częściami aplikacji M (model), V (widok), C (kontroler).

Kontroler zawiera w sobie konstrukcje sterujące, przyjmuje dane od użytkownika i na ich podstawie decyduje o potrzebnych danych prosi o nie model, on zaś kontaktując się np. z mysql pobiera je i przekazuje kontrolerowi, kontroler wywołuje odpowiedni widok i wysyła mu gotowe dane do wyświetlenia. Widok zawiera kod html i wstawki php z danymi otrzymanymi od kontrolera. Pomieszane? Nieee, wystarczy zobaczyć jak taki podział funkcjonuje i dostrzec jego zalety.

Kontrolery i akcje

Tak jak pisałem już w podczas krótkiego opisu MVC, kontroler decyduje o przyjęciu, zarządzaniu danymi kierując naszą aplikacją od czasu wywołania do przekazania danych do widoku.

Zaczniemy od początku, nowo stworzony projekt ma dwa kontrolery index i error odpowiednio w plikach IndexController.php i ErrorController.php w katalogu z kontrolerami.

W pliku IndexController.php znajduje się kod kontrolera:

<?php

class IndexController extends Zend_Controller_Action
{
    public function init()
    {
        /* kod uruchamiany przy starcie kontrolera index */
    }

    public function indexAction()
    {
        // akcja kontrolera index
    }

}

Jak widzimy kontroler definiujemy poprzez utworzenie pliku o nazwie Nazwa_kontroleraController.php w odpowiednim katalogu, a w jego wnętrzu jest zadeklarowana klasa o nazwie Nazwa_kontroleraController dziedzicząca po Zend_Controller_Action. 

W wnętrzu klasy widzimy metody, metody naszego autorstwa jak i aplikacji. Metoda init(){…}jest wywoływana zawsze przy użyciu kontrolera w którym jest zamieszczona, jej rolę można porównać do konstruktora, możemy w niej zadeklarować zmienne używane przez akcję, szablon itd. Drugą metodą jest indexAction(){…} jest to akcja naszego kontrolera, możemy zdeklarować ich dowolną ilość, a ich nazwa składa się z nazwy akcji i tekstu Action, w całości nazwa_akcjiAction().

Jak uruchomić kontroler i akcje

Czas zobaczyć pierwsze efekty naszych działań – zaczynamy. Przenosimy pliki naszego projektu do folderu www, przypominam że głównym katalogiem servera powinien być katalog www/public.

Załóżmy posiadanie domeny domena.pl równie dobrze może być nią localhost. Standardowo Zend używa pliku .htaccess do przekierowywania wszystkich wywołań nie kierujących do istniejącego zasobu na plik index.php który inicjuje naszą aplikację, zgodnie z tą zasadą linki:

• www.domena.pl
• www.domena.pl/index.php
• www.domena.pl/index.php/index
• www.domena.pl/index.php/index/index
• www.domena.pl/index
• www.domena.pl/index/index

• www.domena.pl/nie_istniejący_plik.php

Dadzą taki sam efekt czyli uruchomią plik index.php umieszczony w katalogu public, co będzie równoznaczne z uruchomieniem naszej aplikacji.

Pierwsza grupa linków uruchomią kontroler o nazwie index i kontroler o takiej samej nazwie, z tego możemy wywnioskować – gdy nie zostanie podana nazwa kontrolera lub/i akcji automatycznie zostanie uruchomiona akcja index z kontrolera index, zaś gdy podamy sam kontroler domyślnie zostanie uruchomiona jego akcja index.

Po wejściu na te linki powinniśmy zobaczyć standardowy ekran Zf:

Mając powyższe na uwadze możemy zapisać wzór:

www.domena.pl/nazwa_kontrolera/nazwa_akcji

Uruchomi on kontroler nazwa_kontrolera i akcje nazwa_akcji, jeśli nie zostaną zdeklarowane zostanie użyte standardowe o nazwie index.

Co się stanie gdy podamy nie istniejący kontroler lub akcję?

Gdy system nie będzie mógł odnaleźć wskazanej przez nas akcji bądź kontrolera zostanie uruchomiony kontroler error i jego akcja error, domyślnie po stworzeniu projektu taki kontroler istnieje i zajmuje się zarządzaniem błędami jego kod możemy znaleźć w katalogu aplication/controller/error. Zobaczmy więc jak będzie wyglądała strona błędu, poniższe linki są jednoznaczne:

• www.domena.pl/nie_ma_takiego_kontrolera
• www.domena.pl/index/nie_ma_takiego_kontrolera
• www.domena.pl/error/error

Strona będzie wyglądać tak:

Widoki

Na koniec przydało by się coś wspomnieć o widokach aplikacji, znajdują się do katalogu views i działają niczym szablony w akcjach przekazujemy do nich zmienne, a w nich je wyświetlamy używając php i klas Zend’a w przeciwieństwie np. od Smarty który ma własny język szablonów zamieniany na kod php.

Widoki odpowiadają akcjom, uruchamiając kontroler index i akcję index w katalogu z plikami widoków application\views\scripts musi istnieć katalog o nazwie kontrolera a w nim plik o nazwie akcji z rozszerzeniem .phtml. Zostanie on wywołany w momencie uruchomienie akcji mu odpowiadającej.

Nie chcę wgryzać się głębiej w widok ponieważ musiał bym tłumaczyć jego działanie, a tym się zajmę w innym wpisie, nadmienię że brak widoku aktywowanej akcji doprowadzi do błędu w aplikacji.

Podsumowanie

Dowiedzieliśmy się jak stworzyć projekt, czym są kontrolery, akcje i jak funkcjonują. Jest to sam wstęp wstępu więc czekajcie na następne wpisy, ale dzięki tym informacją każdy z Was powinien móc utworzyć statyczną stronę z kilkoma podstronami.

Mam nadzieję, że język jak i przykłady przytaczane są dość jasne i każdy z Was zrozumiał co miałem na myśli, nie jestem specjalistą od pióra, a przynajmniej nie w pisaniu poradników, co mam nadzieję się zmieni postaram się by każdy kolejny tekst był lepszy i lepszy od poprzedniego.

Dowiemy się co to takiego jest ten „Zend Framework”, gdzie można poczytać na jego temat, dla kogo jest skierowany i w czym może nam pomóc, wspomnę również o lekturach dla początkujących w które można lecz nie trzeba się zaopatrzyć.

Czym jest Zend Framework?

Zend jak każdy framework jest aplikacją, a w zasadzie tylko jej szkicem daje nam wiele możliwości i znacznie upraszcza pracę z kodem, choć na początku ogrom informacji w jaki musimy się zaopatrzyć może wskazywać na coś zupełnie innego. Zf daje nam wiele klas które możemy wykorzystać w naszych projektach od prostych operacji na bazie poprzez tworzenie i wyświetlanie plików pdf, aż do bibliotek obsługujących za nas całą robotę związaną z formularzami.

www.framework.zend.com

Główna strona projektu - Zend Framework możemy z niej pobrać aktualne wydanie fw (1.11.11) jak i wersję testowe (2.0.0beta1). Strona zapewnia nam obszerną dokumentację w kilku językach, niestety język polski był dostępny tylko do czasu i tylko w części, jego kopię można znaleźć na www.zend-framework.pl/manual. Tak jak pisałem jest częściowo przetłumaczona, dla osób nie znających j. angielskiego jest to jakieś wyjście. Tłumaczenie trwa jednak nadchodzący ZF2 różniący się dość sporo do swojego poprzednika zniechęca tłumaczy – szkoda ich pracy.

ZF dla każdego?

Nie, stanowczo nie! Jeśli nie znasz OOP lub podstaw php czas zacząć naukę – nie znając mechanizmów działania programowania obiektowego ciężko zabierać się za pracę z urządzeniem wyciskającym z niego ósme soki. W sieci znajduje się bardzo dużo kursów dla początkujących i średnio zaawansowanych – wystarczy poszukać. Jednak jak masz podstawy to możesz wystartować z tym potworem już po kilku godzinach, a Twój projekt będzie czymś więcej niż „Hello word”.

Zend przede wszystkim pokazuje nam jak powinien wyglądać przepływ informacji i dostarcza ogromną ilość gotowych modułów odwalających za nas brudną robotę, idealnym przykładem jest Zend_Form, za pomocą tej klasy możemy stworzyć formularz, dodać do niego odpowiednie ograniczenia i od tej pory wyświetlanie formularzu odbywa się poprzez wpisanie jednej linii kodu, gdy zostanie on wysłany zf sam sprawdzi wszystkie pola wedle kryterium podanego wcześniej i w razie potrzeby wygeneruje odpowiedni błąd. Tworzenie takiego formularza ogranicza się tak na prawdę do stworzenia klasy, a w jej ciele użycie kilku funkcji – ciężko to opisać bez przykładów a nie chcę mieszać już na starcie.

Książki o Zf

Na rynku w języku polskim jest niewiele książek,które tak na prawdę mogą się nam przydać, jedynym wartym polecenia i w miarę aktualnym jest „Zend Framework od podstaw” Włodzimierza Gajdy ~530 stron tylko o Zend’zie za 89zł, Helion często daje rabaty wystarczy codziennie sprawdzać tutaj.

Podsumowanie

Suche informacje, bez kodu by nie wprowadzać zamieszania, warto przeczytać by mieć jakiś pogląd na sytuację i nie podbijać słońca z pióropuszem na głowie.

Nazywam się Damian Load Domański, a to jest mój dzienniczek w którym zamierzam opisywać co ciekawsze doświadczenia z informatyką i wszystkim co jest z nią związane mam nadzieję, że nikt się nie pogniewa by ten blog był wykorzystywany również jak portfolio.

Kim jestem

Skromny 20 latek zaciekawiony internetem i ludzkimi osobowościami, zamieszkały w pięknym małym mieście jakim jest Świdnik (okolice Lublina) – o tym pięknym miasteczku można by sporo pisać więc polecam dla miłośników historii.

Programowaniem interesuję się od dobrych 8 lat, pierwsze kroki stawiałem uczęszczając do szkoły podstawowej – o ile programowaniem można było nazwać tworzenie stron w pajączku, widząc jednak spore braki tego narzędzia szybko zacząłem przygodę z html’em, php, mysql’em i css’em – dokładnie w tej kolejności, nie wiem czemu, ale css wydawał się strasznie zamieszany w porównaniu do php choć sam już nie wiem czym nie była to po prostu chęć podbicia świata. Tego czasu byłem maluszkiem chcącym wiedzieć o informatyce wszystko, więc php dawało większe możliwości i jakąś interaktywność. Jenak wróciłem do nauki podstaw i cięcie grafiki jest na chwile obecną moim ulubionym zajęciem.

Tutaj już po pewnym czasie, mając kilka projektów odpłatnych za sobą zacząłem cierpieć z powodu braku narzędzi do pracy, cięcie grafiki i podpinanie jakiś prostych autorskich cms’ów zaczęło być nudne – tutaj gdzieś zaczął się z php.pl i czytaniem wielu blogów tematycznych, poznanie kilku świetnych ludzi i próby nauki framework’ów.

Pojawił się serwis nastolatek.pl (teraz nastek.pl) i jego administracja, całkiem spory portal z ogromnym forum, wraz z innym programistą przez ponad rok czuwaliśmy pieczę nad kodem rozwijając i poprawiając go. Niestety serwis został wykupiony przez gg i przejęty przez ich wewnętrznych specjalistów – o ich pracy już nic mówił nie będę.

Przyszłość

Teraz trochę czasu już minęło, projektów się przesypało i myślę nad własnym projektem, z czasem wszystko stanie się jasne. A tymczasem będę pisać bloga o postępach prac jak i postaram się poprowadzić kurs Zend Framework naprzemian z jQuery, nie obiecuję jakiejś rozkładówki, ale możecie być pewni pojawienia się kilku wpisów.

Projekt Cmsss.pl

Projekt jest w wczesnej fazie rozwoju, zbierania ludzi jak i stawiania celów, zobaczymy co z tego wyjdzie.

Ogólnie pisząc ma za zadania dostarczyć narzędzia początkującym programistom jak i przekonać ich do korzystania z framework’ów – a w jaki sposób, to już tajemnica!

Podsumowanie

Nie chciałem się tutaj jakoś rozpisywać, więc jest to krótki wpis o niczym jak i o wszystkim. Strona ma szablon o statusie „w budowie”, z czasem coś podreperuję – całość była przygotowywana pod autorski cms i przystosowana „na szybko” do wordpres.