PHP eVERYWHERE

[JSON] Podstawy i struktura formatu JSON

2015-06-04T00:44:00.001+02:00

JSON to skrót od JavaScript Object Notation, w wolnym tłumaczeniu Notacja Obiektowa JavaScriptu. Jak sama nazwa wskazuje, format stanowi podzbiór języka JavaScript, w którym to służy on jako wewnętrzny język do opisywania obiektów. Nie ogranicza to bynajmniej pola, na którym można go stosować do samego tylko JavaScriptu, a wręcz przeciwnie - pomimo nazwy format ten jest używany powszechnie do wymiany danych we wszystkich praktycznie językach. Jest absolutnie niezależny od platformy, gdyż jego implementacja moze znaleźć się w praktycznie dowolnej aplikacji. Jest to zatem bardzo uniwersalny format, z powodzeniem wykorzystywany w celu wymiany danych pomiędzy aplikacjami. JSON jest bardzo lekkim formatem - jego składnia ograniczona jest do minimum, jest to wręcz banalnie prosty, tekstowy format, w którym poza samymi danymi stosuje się raptem kilka innych ograniczników, takich jak przecinek, czy nawiasy. Przez taki minimalizm jest on niestety trochę mniej czytelny dla człowieka, niż np. XML, ale za to nadrabia małym rozmiarem, gdyż nie posiada w sobie żadnych elementów takich jak znaczniki w XML-u. Warto znać JSON-a, gdyż jest on bardzo przydatny w wymianie danych, szczególnie sieciowych. W artykule tym omówimy podstawowe rzeczy, takie jak składnia, a w następnych artykułach zobaczymy jak pracować na danych z JSON-a w językach PHP i Javascript.

Podstawowe zasady

W JSON-ie obowiązuje kilka kluczowych reguł jakich należy się trzymać podczas tworzenia pliku JSON:

każdy dokument powinien być kodowany w UTF-8
każdy dokument JSON musi zawierać się w głównym nawiasie klamrowym
każdy dokument musi zawierać jeden główny element, w którym zawiera się cała reszta
wszystkie nazwy elementów/kluczy i ich wartości objęte muszą być cudzysłowami
pary klucz-wartość oddzielamy dwukropkiem (klucz : wartość)
elementy występujące obok siebie oddzielamy przecinkiem
zawartość elementu obejmujemy w nawiasy klamrowe
tablice obejmujemy w nawiasy kwadratowe

Struktura JSON-a

Każdy plik JSON musi zawierac się w jednym głównym nawiasie klamrowym, najprostszy, pusty dokument JSON wyglądać będzie więc tak:
[code]
{

}[/code]
Dodajmy teraz nazwę dla głównego elementu, który jest wymagany, niech to będzie np. "rodzina":
[code]
{
"rodzina": {

}
}[/code]
W JSON-ie każdą definicję obiektu/elementu, która zawierać będzie więcej niż jedno pole obejmujemy w nawias klamrowy.
Dodajmy teraz jakiś element do naszego głównego elementu, niech to będzie np. pole o nazwie "nazwa".
W JSON-ie wartości dla danych pól podajemy na zasadzie:
[code]"klucz" : "wartość"[/code]
a w przypadku, gdy mamy do podania wartości kilku pól, to rodzielamy je przecinkiem:
[code]
{
"klucz1" : "wartość1",
"klucz2" : "wartość2",
"klucz3" : "wartość3"
}[/code]
Jak widzimy, w przypadku ilości większej, niż jedno pole całość obejmujemy w nawias klamrowy.
Dodajmy teraz pole "nazwa" do naszego głównego elementu:
[code]
{
"rodzina": {
"nazwa" : "Kowalscy"
}
}[/code]
Powyższy zapis w XML-u wyglądałby tak:

XML:

[code]
<rodzina>
<nazwa>Kowalscy</nazwa>
</rodzina>[/code]

Teraz dodajmy kolejny element o nazwie "dziadkowie":
[code]
{
"rodzina": {
"nazwa" : "Kowalscy",
"dziadkowie" : {

}
}
}[/code]
A w nim kolejny element o nazwie "dziadek" z polami:

imie
nazwisko
oraz element "dzieci", w którym znajdą się kolejne elementy:

[code]
{
"rodzina": {
"nazwa" : "Kowalscy",
"dziadkowie" : {
"dziadek" : {
"imie" : "Alojzy",
"nazwisko" : "Kowalski",
"dzieci" : {

}
}
}
}
}[/code]
Powyższy zapis w XML-u wyglądałby tak:

XML:

[code]
<rodzina>
<nazwa>Kowalscy</nazwa>
<dziadkowie>
<dziadek>
<imie>Alojzy</imie>
<nazwisko>Kowalski</nazwisko>
<dzieci>
</dzieci>
</dziadek>
</dziadkowie>
</rodzina>[/code]

A w widoku drzewka wygląda to tak:

Jak teraz dodać innego dziadka?
Zrobienie tego w poniższy sposób będzie błędne:
[code]
{
"rodzina": {
"nazwa" : "Kowalscy",
"dziadkowie" : {
"dziadek" : {
"imie" : "Alojzy",
"nazwisko" : "Kowalski",
"dzieci" : {

}
`},
"dziadek" : {
"imie" : "Alfred",
"nazwisko" : "Kowalski",
"dzieci" : {

}
}
}
}
}[/code]

Otóż musimy naszych dziadków ująć w tablicę, a robimy to za pomocą nawiasów kwadratowych:
[code]
{
"rodzina": {
"nazwa" : "Kowalscy",
"dziadkowie" : [
{"imie" : "Alojzy", "nazwisko" : "Kowalski", "dzieci" : {} },
{"imie" : "Albert", "nazwisko" : "Kowalski", "dzieci" : {} }
]
}
}[/code]

Powyższy zapis w XML-u wyglądałby tak:

XML:

[code]
<rodzina>
<nazwa>Kowalscy</nazwa>
<dziadkowie>
<dziadek>
<imie>Alojzy</imie>
<nazwisko>Kowalski</nazwisko>
<dzieci>
</dzieci>
</dziadek>
<dziadek>
<imie>Albert</imie>
<nazwisko>Kowalski</nazwisko>
<dzieci>
</dzieci>
</dziadek>
</dziadkowie>
</rodzina>[/code]

A w widoku drzewka prezentuje się tak:

Jak więc widzimy elementy tablicowe umieszczamy w nawiasach kwadratowych, na zasadzie:
[code]
"tablica" : [
{"elementA1" : "wartośćA1", "elementA2" : "wartośćA2"},
{"elementB1" : "wartośćB1", "elementB2" : "wartośćB2"},
...
][/code]

Następnie dodać możemy kolejne zagnieżdżone elementy, jak "ojcowie", "synowie", "wnukowie" itd. Ale z tym już polecam poeksperymentować w ramach pracy domowej i pooglądać sobie wyniki swojej pracy na: http://codebeautify.org/jsonviewer

Wykorzystanie JSON-a

JSON jest powszechnie wykorzystywany w komunikacji sieciowej. Dane przesyłane JSON-em są najzwyczajniej w świecie przesyłane szybciej, gdyż objętość dokumentu JSON jest mniejsza, niż dokumentu z tymi samymi danymi zapisanymi w formacie XML. Jest w związku z tym również szeroko stosowany podczas przesyania danych AJAX-em. JSON jest ponadto wewnętrznie wykorzystywany przez Javascript jako jego naturalny język zapisu obiektów. Praca z JSON-em jest wygodna zarówno po stronie Javascriptu, jak i PHP, gdzie możemy dowolnie wymieniać się danymi. Ponadto konwersja pomiędzy JSON-em, a XML-em jest dziecinnie prosta, tak samo jak serializacja i deserializacja obiektów i tablic robiona przy pomocy formatu JSON-a. W następnym artykule poznamy metody służące do pracy z tym formatem, zarówno w PHP, jak i w Javascripcie.

[XML] Podstawy, składnia i przestrzenie nazw w XML

2015-06-03T22:19:00.000+02:00

XML, czyli EXtensible Markup Language jest uniwersalnym językiem służącym do opisu danych przy pomocy znaczników. Od lat jest niekwestionowanym standardem jeżeli chodzi o zapisywanie zbiorów danych. Nie ma praktycznie języka, który nie posiadałby lub nie mógł posiadać implementacji XML-a. Czyni to XML-a językiem niesamowicie uniwersalnym, całkowicie niezależnym od danej platformy, architektury, czy rodzaju oprogramowania. Za pomocą XML-a komunikować się może praktycznie każdy z każdym i wszystko ze wszystkim, co jest zresztą powszechnie wykorzystywane - w końcu właśnie w tym celu ten język powstał. Kolejnym atutem XML-a jest jego prosta budowa oparta na znacznikach. Poza tym jest łatwiejszy w czytaniu dla człowieka niż np. JSON - nie stanowi żadnego problemu "przeczytanie" prostego dokumentu XML bez użycia żadnych parsujących narzędzi. W artykule tym po krótce omówimy sobie strukturę dokumentów XML, a w następnych artykułach przeanalizujemy tworzenie, odczyt i przetwarzanie dokumentów XML za pomocą PHP oraz Javascriptu.

Definicja standardu

Każdy dokument XML zaczynamy od definicji standardu XML dokumentu i podania kodowania znaków dla niego:
[code]<?xml version="1.0" encoding="UTF-8"?>[/code]
Możemy pominąć podawanie tych parametrów, przyjęte zostaną wtedy wartości domyślne, takie jak powyżej, jednakże przyjęło się, że podajemy taką definicję na początku każdego dokumentu.

Przykład prostego dokumentu XML
[code]<?xml version="1.0" encoding="UTF-8"?>
<books category="fantasy">
<book>
<title>Hobbit</title>
<author>J.R.R. Tolkien</author>
</book>
<book>
<title>Wieża Jaskółki</title>
<author>Andrzej Sapkowski</author>
</book>
</books>[/code]

Znaczniki

Struktura dokumentu opiera się na znacznikach, w których opisujemy poszczególne elementy. Znacznik taki ma postać:
[code]<znacznik>jakaś zawartość</znacznik>[/code]
Przykładowo, opisując tytuł książki, możemy opisać go znacznikiem:
[code]<title>Pan Tadeusz</title>[/code]

Każdy znacznik może posiadać atrybuty go opisujące, które definiujemy następująco:
[code]<znacznik atrybut1="wartość1" atrybut2="wartość2" [...]>[/code]
Przykładowo:
[code]<person name="Jan Kowalski" age="28">[/code]

Znaczniki można w sobie zagnieżdzać, tj. każdy znacznik może posiadać w sobie kolejne znaczniki. Mówimy wtedy, że znacznik położony wyżej jest rodzicem znacznika położonego niżej, a znacznik położony niżej w hierarchi jest dzieckiem znacznika, w którym się zawiera. Popatrzmy na przykład z książką:
[code]<book>
<title>Pan Tadeusz</title>
<author>Adam Mickiewicz</author>
</book>[/code]
Znaczniki <title> i <author> są dziećmi znacznika <book> (zawierają się w nim), jednocześnie znacznik <book> jest tutaj ich rodzicem. Zagnieżdżać możemy oczywiście głębiej, popatrzmy na przykład:
[code]
<shop>
<books category="poemat">
<book>
<title>Pan Tadeusz</title>
<author>
<first_name>Adam</first_name>
<last_name>Mickiewicz</last_name>
</author>
</book>
</books>
</shop>[/code]

Składnia i restrykcje

XML jest bardzo restrykcyjny jeśli chodzi o składnię:
W każdym dokumencie musi istnieć jeden nadrzędny, główny znacznik, w którym zawierać się będą pozostałe.
Znacznik główny nazywamy korzeniem (root). W przypadku powyżej takim root-em dokumentu jest <shop></shop>.

Wszystkie znaczniki muszą zostać zamknięte w odpowiedniej kolejności - tak jak zostały otwarte.
Przykład niepoprawny:
[code]<books>
<book>
<title>Pan Tadeusz</title>
<author>Adam Mickiewicz</author>
</books>
</book>[/code]

Przykład poprawny:
[code]<books>
<book>
<title>Pan Tadeusz</title>
<author>Adam Mickiewicz</author>
</book>
</books>[/code]

Wszystkie puste znaczniki, a więc takie które nie posiadają znacznika zamykającego:
[code]<znacznik></znacznik>[/code]
muszą zostać domknięte za pomocą:
[code]<znacznik />[/code]

Nazwa znacznika może składać się ze znaków alfanumerycznych (litery a-z, A-Z, cyfry 0-9), nie powinna zawierać polskich znaków. W nazwie znacznika możemy użyć trzech znaków specjalnych:

podkreślnika - "_"
myślnika - "-"
i kropki - "."

Pozostałe znaki specjalne są zabronione. Ponadto nazwa znacznika nie może rozpoczynać się od znaku specjalnego oraz od ciągu "xml", "XML", "Xml" i pozostałych konfiguracji słowa "xml".

Wszystkie znaczniki HTML ujęte pomiędzy znaczniki XML muszą zostać zamienione na encje.

Nigdzie w dokumencie (poza otwieraniem i zamykaniem znaczników) nie wolno nam użyć znaków:

< (lt)
> (gt)
& (ampersand)

Musimy zamienić je na encje:

< na <
> na >
& na &

Wartości atrybutów podajemy zawsze w cudzysłowach lub apostrofach.

Komentarze w dokumencie XML umieszczamy podobnie jak w HTML-u:
[code][/code]

Wszystko to co ma nie być przetwarzane przez parser XML umieszczamy w bloku:
[code]<![CDATA[
...
]]>[/code]

Walidacja

Dokument XML przygotowany lub wygenerowany niepoprawnie nie zostanie sparsowany. W sieci istnieje cała masa stron oferujących sprawdzanie poprawności składni dokumentów XML, są to tzw. walidatory. Przykładowo jeden z nich: https://validator.w3.org/ - walidator oferuje możliwość sprawdzenia dokumentu XML po podaniu jego URL-a, pliku lokalnego lub dokumentu wklejonego bezpośrednio do formularza. A na tej stronie wygenerujemy sobie widok drzewka z dokumentu XML: http://codebeautify.org/xmlviewer

Przestrzenie nazw

Przestrzenie nazw (namespaces) zostały stworzone w celu zdefiniowania sposobu opisu znaczników, które mogą mieć różne znaczenie w zależności od typu elementu. Przykładowo - znacznik <title> może mieć jasno określone znaczenie dla danego typu elementu, ale dla innego typu może już oznaczać coś innego. Inny przykład: w jednym dokumencie może znaleźć się opis książki oraz opis faktury za nią. W obu przypadkach istnieć może znacznik <author>, tyle tylko, że w przypadku książki oznacza on autora książki, a w przypadku faktury osobę ją wystawiającą. Jak aplikacja przetwarzająca takiego XML-a ma teraz to odróżnić i nie stwierdzić, że osobą wystawiającą fakturę za "Pana Tadeusza" jest np. Adam Mickiewicz? Dlatego właśnie wprowadzono nazewnictwo oparte na przestrzeniach nazw. Kolejną korzyścią jest to, iż w jednym dokumencie możemy wykorzystać tyle przestrzeni ile tylko chcemy, tak więc przykładowy znacznik <title> wykorzystać możemy w jednym dokumencie w kilku różnych kontekstach - różnych dla każdej z przestrzeni nazw.

Przestrzeń nazw z jakiej będziemy korzystać określamy za pomocą:
[code]xmlns:PREFIX = "URI_DO_SPECYFIKACJI"[/code]

gdzie:

xmlns - to nazwa specjalnego atrybutu, którym określamy przestrzeń (xmlns to skrót od XML NameSpace)
PREFIX - określa skróconą nazwę przestrzeni, czyli jej prefix, który dodawać będziemy później do znaczników
URI_DO_SPECYFIKACJI - adres prowadzący do opisu danej przestrzeni nazw. W zasadzie może on nawet prowadzić do nikąd, choć wg zaleceń prowadzić powinien on do dokumentu opisującego daną przestrzeń.

Przykładowa definicja przestrzeni nazw:
[code]<b:book xmlns:b="http://books.com/ns">
<b:author>Adam Mickiewicz</b:author>
<b:title>Pan Tadeusz</b:title>
</b:book>[/code]

Jak widać korzystamy tutaj z trzech znaczników:

<book>
<author>
<title>

Każdy z nich deklarowany jest w przestrzeni nazw:
[code]http://books.com/ns[/code]
której skrótowym prefixem jest:
[code]b[/code]

Nazwę znacznika w danej przestrzeni definiujemy na zasadzie:
[code]<PREFIX:ZNACZNIK>[/code]
w naszym przykładzie:
[code]<b:book>
<b:author>
<b:title>[/code]
Należy tutaj pamiętać, że również i znaczniki zamykające muszą posiadać prefiksy przestrzeni nazw, o ile taki wystąpił w znaczniku otwierającym.

Przestrzeń nazw obowiązuje od miejsca jej zadeklarowania, tak więc nie możemy najpierw użyć znaczników z danej przestrzeni, a dopiero później jej zadeklarować.
Ponadto - przestrzeń nazw obowiązuje jedynie dla znacznika, w którym została określona oraz we wszystkich znacznikach w nim zawartych (bez względu na stopien zagnieżdżenia)
Zdefiniowanie zatem przestrzeni w głównym elemencie dokumentu spowoduje, że przestrzeń będzie obowiązywać dla całego dokumentu, gdyż wszystkie pozostałe znaczniki się w nim zawierają.

Można także stworzyć przestrzeń nazw domyślną dla wszystkich elementów zawierających.
W przypadku takim nie musimy już podawać prefixa przestrzeni przy znacznikach dzieci.
Deklaracja przestrzeni domyślnej odbywa się również bez podawania prefixu:
Przykład:
[code]<book xmlns="http://books.com/ns">
<author>Adam Mickiewicz</author>
<title>Pan Tadeusz</title>
<book>[/code]

W powyższym przykładzie wszystkie znaczniki zawarte pomiędzy <book></book> znajdują się domyślnie w przestrzeni nazw "http://books.com/ns".

Przestrzenie nazw mogą również dotyczyć atrybutów:
[code]<b:book xmlns:b="http://books.com/ns" b:hardcover="yes">
<b:author>Adam Mickiewicz</b:author>
<b:title>Pan Tadeusz</b:title>
</b:book>[/code]

Jeśli dla danego znacznika nie jest zdefiniowana żadna przestrzeń nazw to mówimy, ze występuje on w domyślnej, globalnej przestrzeni nazw.

[PHP][Propel] Instalacja oraz wstęp do Propel ORM

2015-06-03T18:58:00.000+02:00

Propel do biblioteka służąca do mapowania obiektowo-relacyjnego, w skrócie ORM. Podobnie jak biblioteka Doctrine sprawia on, że praca na bazie danych odbywa się za pomocą zwykłych obiektów. Jest odrobinę łatwiejszy w użyciu, niż Doctrine, co jednak nie znaczy, że jest gorszy. Praca z obiema bibliotekami jest w zasadzie podobna, opiera się ona na przygotowaniu schematu bazy danych, wygenerowaniu odpowiednich metod dla modelu, a następnie na pracy na modelu jak na zwykłych obiektach. Propela, podobnie jak Doctrine możemy w prosty sposób połączyć z popularnymi frameworkami, jak Zend, czy Symfony - integracja taka zostanie tutaj opisana w którymś z artykułów. W poniższym natomiast artykule pobierzemy i zainstalujemy sobie bibliotekę Propela, skonfigurujemy ją, uruchomimy, a następnie przygotujemy prosty, testowy model bazy i zobaczymy jak to mniej więcej działa. Artykuł przedstawia procedurę w systemach Windows, na Linuxach jednak wszystko (poza oczywiście innymi ścieżkami) wygląda podobnie.

Instalacja Propel ORM

Oficjalna strona Propela to: http://propelorm.org.
Samego Propela pobierzemy sobie za pomocą Composera, przygotowując plik "composer.json" w odpowiednim katalogu dla naszego projektu. Na potrzeby artykułu niech będzie to katalog:
[code]C:/www/propel[/code]
(na screenach będzie to u mnie c:/wamp/www/propel/)
W stworzonym katalogu utwórzmy plik "composer.json" o treści:
[code]
{
"require": {
"propel/propel": "~2.0@dev"
}
}[/code]
zapiszmy, a następnie będąc w utworzonym katalogu zainstalujmy z poziomu terminala:
[code]
$ cd c:/www/propel
$ composer install[/code]
Pobierze to nam najnowszą wersję Propela z gałęzi 2.x.

Możemy też pobrać za pomocą Gita:
[code]
$ cd c:/www
$ git clone git://github.com/propelorm/Propel2.git propel[/code]

lub zwyczajnie pobrać plik .zip lub .tar.gz ze strony projektu i rozpakować do c:/www/propel. Ja polecam jednak metodę z Composerem.

Propel wraz z biblioteką zainstaluje nam małe narzędzie konsolowe w katalogu:
[code]/vendor/bin[/code]
które posłuży nam później do zautomatyzowania wielu operacji.
Jeśli chcemy później korzystać z polecenia propel bez podawania ścieżki, dodajmy ten folder do zmiennej PATH w Windowsie.

Pierwszy projekt

Możemu już zainicjować swój pierwszy projekt i możemy to zrobić na dwa sposoby: ręcznie, lub za pomocą narzędzia konsolowego, które lekko nam ten proces zautomatyzuje.

Pół automatycznie zrobimy to za pomocą:
[code]$ propel init[/code]
My jednak omówmy sobie ręczne przygotowanie Propela.

Testowa baza

Dobrze byłoby abyśmy na starcie mieli conajmniej dwie tabele, tak aby pokazać definicję kluczy obcych, zrobimy więc podobną strukturę jak w dokumentacji Propela, czyli sklep z książkami. Nasza testowa baza będzie mieć nazwę "shop" i składać się będzie z dwóch prostych tabel:

book
author

Tabela: book

Nazwa pola	Typ	Dodatkowe	Klucz obcy	Opis
id	integer	PRIMARY KEY, AUTO_INCREMENT, NOT NULL		ID książki
title	varchar(255)	NOT NULL		tytuł książki
author_id	integer	NOT NULL	author.id	ID autora
price	integer	NOT NULL		cena książki

Tabela: author

Nazwa pola	Typ	Dodatkowe	Opis
id	integer	PRIMARY KEY, AUTO_INCREMENT, NOT NULL	ID autora
first_name	varchar(100)	NOT NULL	imię autora
last_name	varchar(100)	NOT NULL	nazwisko autora

Uwaga: bazy na razie nie tworzymy, wyobraźmy sobie jedynie jej strukturę.

Schemat bazy - schema.xml

Na początek utworzyć musimy opis struktury naszej bazy w pliku:
[code]schema.xml[/code]
Plik ten zapisujemy w katalogu głównym naszego projektu, czyli w naszym przypadku w:
[code]c:/www/propel/[/code]

Jak już widać po rozszerzeniu, opis naszej bazy przygotowywać będziemy w języku XML.

1) <database>

Głównym tagiem w pliku XML musi być zawsze tag <database>, a w jego atrybutach powinniśmy podać nazwę naszej bazy oraz sposób w jaki będą inkrementowane wartości w polach typu "auto increment". Domyślnie jest to "native", co oznacza mniej więcej tyle, iż zajmie się tym automatycznie już sama baza.
[code]<?xml version="1.0" encoding="UTF-8"?>
<database name="shop" defaultIdMethod="native">

</database>[/code]

2) <table>

Następnie zdefiniować musimy tabele w naszej bazie. Każda tabela musi zostać objęta tagiem <table> a w jej atrybutach musimy podać jej nazwę oraz opjonalnie nazwę klasy dla niej używaną przez Propela, o ile chcemy, aby była inna niż prawdziwa nazwa tabeli. Jeśli nie zdefiniujemy atrybutu "phpName" to Propel automatycznie wykorzysta nazwę tabeli, wykorzystując zapis camelCase, tj. klasa dla tabeli "book" otrzymałaby automatycznie nazwę "Book", a np. klasa dla tabeli "user_config" otrzymała by nazwę "UserConfig" - zgodnie z zapisem formatu camelCase.
[code]<?xml version="1.0" encoding="UTF-8"?>
<database name="shop" defaultIdMethod="native">
<table name="book" phpName="Book">

</table>
<table name="author" phpName="Author">

</table>
</database>[/code]

3) <column>

Mamy już definicję bazy i tabel, pora zdefiniować kolumny w tabelach. Robimy to za pomocą znaczników <column>, podając następujące atrybuty:

name - nazwa kolumny, np. "title"
type - typ kolumny, np. "varchar"
size - długość pola, np "120" dla varchar
required - czy pole jest wymagane, np. "true"
autoIncrement - czy pole jest typu "AUTO INCREMENT", np. "true"
primaryKey - czy pole posiada klucz podstawowy, np. "true"
phpName - analogicznie jak przy nazwie tabeli, możemy podać nazwę pod jaką bedzie dane pole deniniował Propel

Schemat naszej bazy będzie więc w tej chwili wyglądać tak:
[code]
<?xml version="1.0" encoding="UTF-8"?>
<database name="shop" defaultIdMethod="native">
<table name="book" phpName="Book">
<column name="id" type="integer" required="true" primaryKey="true" autoIncrement="true" />
<column name="title" type="varchar" size="255" required="true" />
<column name="author_id" type="integer" required="true" />
<column name="price" type="integer" required="true" />
</table>
<table name="author" phpName="Author">
<column name="id" type="integer" required="true" primaryKey="true" autoIncrement="true" />
<column name="first_name" type="varchar" size="100" required="true" />
<column name="last_name" type="varchar" size="100" required="true" />
</table>
</database>[/code]
Ważna sprawa: zawsze pamiętajmy w XML-u o zamykaniu znaczników, które nie mają taga zamykającego za pomocą:
[code]/>[/code]

Klucze obce

Zdefiniować musimy jeszcze klucze obce dla poszczególnych tabel, dokonujemy tego za pomocą taga:
[code]<foreign-key>[/code]
któremu w atrybutach podajemy:

foreignTable - nazwę obcej tabeli
phpName - opcjonalnie własną nazwę dla relacji, jeśli nie podana, to Propel przypisze tu nazwę z obcej tabeli
refPhpName - opcjonalnie własną nazwę dla relacji, ale widzianą przez obcą tabelę

Przykladowo - nasza tabela "book" zawiera jeden klucz obcy, a jest nim pole "author_id". Relacja prowadzi do tabeli "author" i jej pola "id". Aby teraz zdefiniować relację z tabelą "author", wpiszemy dla tabeli "book" taką definicję:
[code]
<foreign-key foreignTable="author" phpName="Author" refPhpName="Book">

</foreign-key>[/code]

Powyższe określa nam relację z obcą tabelą, musimy teraz jeszcze podać jakich kolumn te relacje dotyczą, robimy to za pomocą taga:
[code]<reference>[/code]
jako atrybuty podając mu:

local - nazwę pola z obecnej tabeli
foreign - nazwę pola z tabeli obcej

Przykladowo - nasza tabela "book" zawiera jeden klucz obcy, a jest nim pole "author_id".
Aby teraz zdefiniować relację z tabelą "author" i jej polem "id", wpiszemy dla tabeli "book" taką definicję:
[code]
<foreign-key foreignTable="author" phpName="Author" refPhpName="Book">
<reference local="author_id" foreign="id" />
</foreign-key>[/code]

Oczywiście dla każdej tabeli możemy podać wiele relacji, użyjemy wtedy kilku tagów <reference>

Finalnie schemat naszej bazy wygląda tak:
[code]
<?xml version="1.0" encoding="UTF-8"?>
<database name="shop" defaultIdMethod="native">
<table name="book" phpName="Book">
<column name="id" type="integer" required="true" primaryKey="true" autoIncrement="true" />
<column name="title" type="varchar" size="255" required="true" />
<column name="author_id" type="integer" required="true" />
<column name="price" type="integer" required="true" />
<foreign-key foreignTable="author" phpName="Author" refPhpName="Book">
<reference local="author_id" foreign="id" />
</foreign-key>
</table>
<table name="author" phpName="Author">
<column name="id" type="integer" required="true" primaryKey="true" autoIncrement="true" />
<column name="first_name" type="varchar" size="100" required="true" />
<column name="last_name" type="varchar" size="100" required="true" />
</table>
</database>[/code]

Zapiszmy więc taki powyższy schemat do pliku:
[code]schema.xml[/code]
Mamy w tym momencie gotowy schemat naszej bazy danych, pora teraz na utworzenie dla niej modelu.

Konfiguracja

Musimy teraz przygotować model dla naszej bazy, czyli wygenerować wszystkie niezbędne klasy, które będą ją opisywały w postaci obiektów, a także wszelkie niezbędne metody, jak gettery i settery, które pozwolą nam na pobieranie i ustawianie wartości pól. Propel zrobi to za nas automatycznie, nie będziemy więc musieli tworzyć klas ręcznie. Na podstawie definicji pobranej ze stworzonego schematu sam wygeneruje odpowiednie klasy i metody. Musimy jednak dokonać małej konfiguracji, podać parametry połączenia itp.
Plik z konfiguracją dla Propela powinien mieć nazwę "propel" oraz rozszerzenie odpowiednie dla języka, w którym został napisany, czyli:
[code]propel.php, propel.xml, propel.json lub propel.yaml[/code]
i powinien zostać umieszczony w tym samym katalogu co plik ze schematem, czyli "schema.xml".
Może zostać również umieszczony w podfolderze "/config" lub "/conf". My na razie umieśćmy go w naszym katalogu głównym, obok pliku "schema.xml".
Plik z konfiguracją, jak już wspomniałem wyżej przygotować możemy w jednym z 4 języków:

PHP
XML
JSON
YAML

Wybór jest dowolny, jednak najczęściej używanym formatem jest YAML, ze względu na swoją prościutką i miłą dla oka składnię. Konfiguracja jest dość rozbudowana i opisana w pełni w dokumentacji Propela, jednakże nie musimy na razie w nią wnikać, gdyż domyślnie Propel wymaga podania jedynie kluczowych informacji, dotyczących nazwy bazy i parametrów naszego połączenia z bazą. Jak pamiętamy, naszą bazę nazwaliśmy w schemacie:
[code]shop[/code]
Stwórzmy więc teraz plik z konfiguracją dla bazy "shop".
W języku YAML będzie miał on taką postać:
[code]
# propel.yaml
propel:
database:
connections:
shop:
adapter: mysql
classname: Propel\Runtime\Connection\ConnectionWrapper
dsn: "mysql:host=localhost;dbname=nazwa_bazy"
user: nazwa_użytkownika_bazy
password: hasło_użytkownika_bazy
attributes:
runtime:
defaultConnection: shop
connections:
- shop
generator:
defaultConnection: shop
connections:
- shop[/code]
gdzie oczywiście w pola:

host - podajemy adres serwera bazy
mysql - tutaj podajemy nazwę adaptera, w przykładzie podałem MySQL
nazwa_bazy - nazwa naszej bazy
nazwa_użytkownika_bazy - nazwa użytkownika
hasło_użytkownika_bazy - i jego hasło

Plik taki zapisujemy jako:
[code]propel.yaml[/code]
Więcej o konfiguracji przeczytacie tutaj: http://propelorm.org/documentation/10-configuration.html

Generowanie SQL

Mamy już dwa pliki:

schema.xml - czyli schemat bazy
propel.yaml - konfigurację bazy

Musimy więc teraz wygenerować zapytanie SQL, które zbuduje nam tabele w bazie na podstawie podanego przez nas schematu. Do wygenerowania takiego zapytania użyjemy oferowanego z Propelem narzędzia:
[code]/vendor/bin/propel[/code]
Wejdźmy teraz w terminalu do katalogu z naszym projektem:
[code]$ cd c:/www/propel[/code]
I wykonajmy następujące polecenie:
[code]$ propel sql:build[/code]
lub
[code]$ "/vendor/bin/propel" sql:build[/code]
jeśli nie dodaliśmy katalogu /vendor/bin do zmiennej PATH w Windowsie.

Narzędzie to utworzyło nam katalog:
[code]/generated_sql[/code]
A w nim 2 pliki:

shop.sql
sqldb.map

Spójrzmy teraz na zawartość pliku "shop.sql":
[code]
# This is a fix for InnoDB in MySQL >= 4.1.x
# It "suspends judgement" for fkey relationships until are tables are set.
SET FOREIGN_KEY_CHECKS = 0;

-- ---------------------------------------------------------------------
-- book
-- ---------------------------------------------------------------------

DROP TABLE IF EXISTS `book`;

CREATE TABLE `book`
(
`id` INTEGER NOT NULL AUTO_INCREMENT,
`title` VARCHAR(255) NOT NULL,
`author_id` INTEGER NOT NULL,
`price` INTEGER NOT NULL,
PRIMARY KEY (`id`),
INDEX `book_fi_ea464c` (`author_id`),
CONSTRAINT `book_fk_ea464c`
FOREIGN KEY (`author_id`)
REFERENCES `author` (`id`)
) ENGINE=InnoDB;

-- ---------------------------------------------------------------------
-- author
-- ---------------------------------------------------------------------

DROP TABLE IF EXISTS `author`;

CREATE TABLE `author`
(
`id` INTEGER NOT NULL AUTO_INCREMENT,
`first_name` VARCHAR(100) NOT NULL,
`last_name` VARCHAR(100) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;

# This restores the fkey checks, after having unset them earlier
SET FOREIGN_KEY_CHECKS = 1;[/code]

Jak widzimy wygenerowaliśmy pełne zapytanie SQL służace do utworzenia tabel w bazie.

Uwaga: każde ponowne użycie polecenia:
[code]$ propel sql:build[/code]
tworzy te zapytanie na nowo, więc musimy je wywołać przy każdej modyfikacji schematu bazy.
Pora teraz na wygenerowanie klas dla modelu.

Generowanie klas modelu

Do wygenerowania wszystkich niezbędnych klas dla naszego modelu ponownie użyjemy polecenia "propel".
Wpiszmy teraz w terminalu:
[code]$ propel model:build[/code]

Wygenerowało to nam katalog:
[code]/generated-classes[/code]
A w nim wszystkie wymagane klasy niezbędne do pracy z naszymi tabelami:

Propel utworzył nam 3 rodzaje klas:

klasę modelu, np. Book, która reprezentuje wiersz z tabeli jako obiekt
klasę zapytań, np. BookQuery, która zawiera definicje metod slużacych do operacji na wierszach/obiektach
klasę mapowania, np. Map/BookTableMap, która zawiera metody statyczne służace do operowania na wierszu/obiekcie

Uwaga: każde ponowne użycie polecenia:
[code]$ propel model:build[/code]
tworzy te klasy na nowo, więc musimy je wywołać przy każdej modyfikacji schematu bazy. Nie należy też w tych klasach umieszczać swojego kodu, gdyż ten przepadnie po kolejnym generowaniu modelu.

Mamy już gotowe klasy modelu, musimy je teraz dołączyć do autoloadera, tak aby były dostępne w naszym kodzie. Zmodyfikujmy więc plik "composer.json" znajdujący się w katalogu głównym, tak aby wyglądał następująco:
[code]
{
"require": {
"propel/propel": "~2.0@dev"
},
"autoload": {
"classmap": ["generated-classes/"]
}
}[/code]
Następnie zaktualizujmy Composera:
[code]$ composer update[/code]

Sprawi to, że przebudujemy autoloader Composera, co za tym idzie, nasze klasy modelu zawarte w katalogu:
[code]/generated-classes[/code]
będą ładowane automatyczne jeśli skorzystamy z autoloadera wygenerowanego przez Composera.

Plik konfiguracyjny

Musimy teraz wygenerować plik z domyślną konfiguracją dla połączenia z bazą danych.
Poprzednio podaliśmy konfigurację w języku YAML, użyjemy teraz polecenia Propela, które na podstawie tego pliku przygotuje nam plik PHP z konfiguracją, który dołączymy do swojego projektu:

[code]$ propel config:convert[/code]

Polecenie utworzyło nam katalog:
[code]/generated-conf[/code]
a w nim plik:
[code]config.php[/code]

o treści:
[code]
<?php
$serviceContainer = \Propel\Runtime\Propel::getServiceContainer();
$serviceContainer->checkVersion('2.0.0-dev');
$serviceContainer->setAdapterClass('shop', 'mysql');
$manager = new \Propel\Runtime\Connection\ConnectionManagerSingle();
$manager->setConfiguration(array (
'classname' => 'Propel\\Runtime\\Connection\\ConnectionWrapper',
'dsn' => 'mysql:host=localhost;dbname=NAZWA_BAZY',
'user' => 'UŻYTKOWNIK',
'password' => 'HASŁO',
'attributes' =>
array (
'ATTR_EMULATE_PREPARES' => false,
),
));
$manager->setName('shop');
$serviceContainer->setConnectionManager('shop', $manager);
$serviceContainer->setDefaultDatasource('shop');[/code]

Utworzenie tabeli w bazie

Przyszła pora na utworzenie naszych opisanych w schemacie tabel w bazie.
Jak pamiętamy, Propel utworzył nam do tego zapytanie SQL, aby teraz wykonać to zapytanie z poziomu Propela, użyjemy polecenia:

[code]$ propel sql:insert[/code]

Utworzyło to nam odpowiednie tabele w bazie danych, co możemy sprawdzić np. za pomocą PHPMyAdmina.

Testujemy

Pozostało nam teraz sprawdzenie działania Propela w praktyce.
Utwórzmy sobie w głównym folderze naszego projektu plik testowy, np.:
[code]test.php[/code]
w którym przetestujemy Propela.

Na początek musimy dołączyć autoloader oraz plik z konfiguracją dla Propela:
[code]
<?php
// test.php
// dołączamy autoloader Composera
require_once __DIR__.'/vendor/autoload.php';

// dołączamy plik z konfiguracją
require_once __DIR__.'/generated-conf/config.php';
?>[/code]

Dodajemy nowy rekord obiekt

Napiszmy teraz prosty kod dodający do bazy nowego autora:
[code]
$author = new Author();
$author->setFirstName('Adam');
$author->setLastName('Mickiewicz');
$book->save();[/code]

Nasz plik "test.php" wyglądać więc będzie w całości tak:
[code]
<?php
// test.php
// dołączamy autoloader Composera
require_once __DIR__.'/vendor/autoload.php';

// dołączamy plik z konfiguracją
require_once __DIR__.'/generated-conf/config.php';

// tworzymy nowego autora
$author = new Author();

// ustawiamy imię i nazwisko
$author->setFirstName('Adam');
$author->setLastName('Mickiewicz');

// zapisujemy
if($author->save())
{
echo 'Dodano autora o id: '.$author->getId();
}
?>[/code]

Wejdźmy teraz na:
[code]http://localhost/propel/test.php[/code]
i zobaczmy, czy wszystko działa:

Voila! Dodaliśmy nowego autora do bazy za pomocą Propela.

Podsumowanie

Jak widzimy, utworzenie nowego rekordu sprowadza się teraz do prostego utworzenia obiektu i wywołania metody "save()". I to tyle tytułem wstępu, w kolejnych artykułach nauczymy się korzystać z Propela, pobierać i aktualizować rekordy, obsługiwać relacje itd. Na chwilę obecną potrafimy już przygotować schemat bazy, zbudować prosty model oraz wiemy jak to wszystko mniej więcej działa, więc na wstęp i wprowadzenie powinno nam wystarczyć.

[PHP][Zend2] Instalacja i podstawy frameworka Zend2

2015-06-02T21:02:00.000+02:00

Zend to jeden z najpopularniejszych i najprzyjemniejszych w użyciu frameworków do PHP. Jest bardzo rozbudowanym środowiskiem, a mimo tego jego nauka nie stwarza większych problemów (jak to czasem może mieć miejsce w przypadku Symfony). Posiada bardzo obszerną dokumentację oraz niesamowicie rozbudowaną społeczność swoich użytkowników, jest więc prawie pewne, że napotykając na dany problem zawsze znajdziemy jakieś rozwiązanie, czy wskazówkę. Za pomocą Zenda stworzyć można praktycznie każdą aplikację webową, zawiera on w sobie bardzo domyślnych komponentów, zaczynając od absolutnie podstawowych, na bardziej wyspecjalizowanych skończywszy. Obecnie rozwijana jest wersja 2 frameworka, a za niedługo światło dzienne ujrzy wersja trzecia. Tutaj zajmiemy się właśnie tą drugą wersją i w cyklu artykułów nauczymy się krok po kroku pisania aplikacji za pomocą frameworka Zend. Na samym początku, podobnie jak w większości artykułów tutaj - cykl tutoriali zaczynamy od opisu instalacji, wstępu i podstawowej konfiguracji środowiska. Zaczynamy więc.

Instalacja

Oficjalną stronę frameworka i sam framework do pobrania znajdziemy pod adresem: http://framework.zend.com, znajduje się tam także obszerna dokumentacja wraz z całą masą przykładów, z którą warto się oczywiście zapoznać. Zainstalować można Zenda na kilka sposobów i z kilku źródeł, my pobierzemy sobie archiwum ze szkieletem aplikacji, ale możemy też pobrać "czystą" wersję w postaci archium .zip ze strony, lub z GitHUB-a: https://github.com/zendframework/zf2.
Instalując natomiast Zenda za pomocą Composera - http://framework.zend.com/downloads/composer - możemy wybrać sobie pakiety jakie chcemy wraz z Zendem zainstalować.
My pobierzemy sobie wersję z aplikacją testową z GitHUB-a, a następnie zainstalujemy ją za pomocą Composera.

Pobierzmy teraz instalkę Zenda z GitHuba którymś z poniższych sposobów:
1) albo klonując repozytorium:
[code]$ cd C:/www/
$ git clone git://github.com/zendframework/ZendSkeletonApplication.git zend[/code]
2) albo jako archiwum .zip: https://github.com/zendframework/ZendSkeletonApplication/archive/master.zip

W drugim przypadku rozpakujmy sobie pliki, np. do folderu:
[code]C:/www/zend[/code]
lub oczywiście gdziekolwiek indziej, na screenach będzie to u mnie "c:/wamp/www/zend", jednakże dla przykładu będę podawał tutaj "c:/www/zend/".

Mając już pobrane lub rozpakiwane pliki, uruchomimy teraz Composera.
Wchodzimy z poziomu terminalu do katalogu z Zendem i wykonujemy polecenie:
[code]$ composer install[/code]

Zend doinstaluje sobie kilka bibliotek i będzie już gotowy do pracy.

Vhost

Następnym krokiem będzie utworzenie vhosta wskazującego na katalog:
[code]/public[/code]
w katalogu z Zendem, czyli w naszym przykładzie:
[code]c:/www/zend/public[/code]
Jest to ważne, gdyż tylko folder /public będziemy udostępniać poprzez WWW. Cała reszta kodu i katalogów będzie z tego poziomu niedostępna. Jak stworzyć vhosta w Apache'u - opisałem krok po kroku w tym artykule.

Tworzymy zatem vhosta wskazującego na katalog /public i nazywamy go np.:
[code]zend.localhost[/code]

Gdy mamy już vhosta wchodzimy na niego, aby sprawdzić, czy Zend zainstalowany został poprawnie.
Jeśli wszystko poszło zgodnie z planem, powinniśmy zobaczyć coś mniej więcej takiego:
[code]http://zend.localhost/[/code]

Struktura katalogów frameworka

Przyjrzyjmy się teraz strukturze katalogów z aplikacją Zenda:

config - zawiera globalne pliki konfiguracyjne
data - zawierać będzie inne pliki, takie jak cache, upload, logi
module - najważniejsza część naszej aplikacji, z definicjami naszych kontrolerów, modeli, widoków itd.
public - folder publiczny dostępny z poziomu WWW, css, pliki js itp.
vendor - zewnętrzne biblioteki, m.in. główne biblioteki frameworka Zend

Moduły, kontrolery, akcje

Najważniejszym dla nas katalogiem będzie /module. To właśnie w nim będziemy trzymać kod naszych kontrolerów, ustawienia, widoki i generalnie całą strukturę naszej aplikacji. Jak widzimy tutaj, w Zendzie każda aplikacja składa się z tzw. modułów. Moduły z koleji składają się z kontrolerów i ich akcji. Naszym głównym modułem może być więc ta część aplikacji, która jest dostępna użytkownikom (front-end), a kolejnym modułem może być sekcja administracyjna dostępna tylko dla administratora (back-end). Z koleji każdy z tych modułów może składać się z wielu kontrolerów, z czego każdy będzie oddzielną sekcją, np. jeden kontroler odpowiedzialny za obsługę użytkowników, inny za obsługę komentarzy na stronie, jeszcze inny za artykuły it. Kontrolery z koleji mogą być podzielone na akcje takie jak: dodaj, edytuj, wyświetl itd.

Na przykładzie tej szkieletowej aplikacji widzimy, że:

aplikacja składa się z jednego modułu o nazwie Application:
/module/Application
moduł Application składa się z jednego domyślnego kontrolera o nazwie IndexController:
/module/Application/src/Application/Controller/IndexController.php
kontroler IndexController składa się z jednej domyślnej akcji: indexAction:

[code]
public function indexAction()
{
return new ViewModel();
}[/code]

Kontroler "Index" powinien być zawsze domyślnym kontrolerem w module, natomiast akcja "index" domyślną akcją w kontrolerze.

Routing

Do poszczególnych kontrolerów i ich akcji dostajemy się w Zendzie na zasadzie:
[code]http://nasza_aplikacja.com/moduł/kontroler/akcja[/code]

Przykładowo:
[code]http://zend.localhost/application/index/index[/code]
zwróci nam akcję "index" z kontrolera "index" z modułu "application".
Identyczne działanie będzie mieć wpisanie adresu:
[code]http://zend.localhost/application/index[/code]
gdzie jak widać podaliśmy jedynie nazwę modułu i kontrolera bez podania akcji, a mimo to wyświetliła nam się akcja "index". Stało się tak, ponieważ akcja "index" jest tutaj akcją domyślną i wywołuje się automatycznie, gdy nie podamy tutaj żadnej innej akcji w wywołaniu. Analogicznie ma się sprawa z kontrolerem:
[code]http://zend.localhost/application[/code]
wywoła kontroler "index" z akcją "index", gdyż kontroler "index" jest tutaj kontrolerem domyślnym.

Konfiguracja modułu - module.config.php

Domyślny kontroler i domyślną akcję możemy zmienić w głównym pliku konfiguracyjnym naszego modułu:
[code]/module/application/config/module.config.php[/code]

Otwórzmy sobie ten plik.
Jak widzimy główna konfiguracja modułu składa się z tablicy:
[code]
array(
"router" => opcje,
"service_manager" => opcje,
"translator" => opcje,
"controllers" => opcje,
"view_manager" => opcje,
"console" => opcje
)[/code]
Poszczególne sekcje konfiguracji omówimy sobie w kolejnych artykułach.

Zobaczmy teraz jak wygląda plik z definicją kontrolera:
[code]/module/Application/src/Application/Controller/IndexController.php[/code]
[code]
<?php
namespace Application\Controller;

use Zend\Mvc\Controller\AbstractActionController;
use Zend\View\Model\ViewModel;

class IndexController extends AbstractActionController
{
public function indexAction()
{
return new ViewModel();
}
}[/code]

Tworzymy własną akcję

Dodajmy do kontrolera Index nową akcję, np. o nazwie "hello":
[code]
<?php
namespace Application\Controller;

use Zend\Mvc\Controller\AbstractActionController;
use Zend\View\Model\ViewModel;

class IndexController extends AbstractActionController
{
public function indexAction()
{
return new ViewModel();
}

// nowa akcja
public function helloAction()
{
return new ViewModel();
}
}[/code]
Zapiszmy plik i zobaczmy co się stanie po wejściu w adres:
[code]http://zend.localhost/application/index/hello[/code]

Jak widać otrzymamy błąd i załadowany zostanie widok określony w pliku:
[code]/module/application/config/module.config.php[/code]
w sekcji:
[code]
'template_map' => array(
'layout/layout' => __DIR__ . '/../view/layout/layout.phtml',
'application/index/index' => __DIR__ . '/../view/application/index/index.phtml',
'error/404' => __DIR__ . '/../view/error/404.phtml', // <<<<<<<< nasz widok z błędem
'error/index' => __DIR__ . '/../view/error/index.phtml',
),[/code]

Warstwa widoku

Aby przejść dalej opowiedzmy sobie o widokach.
Pliki naszego widoku przechowywane są w formie plików:
[code].phtml[/code]
w katalogu:
[code]/module/Application/view/[/code]

Głównym plikiem widoku jest "layout.phtml".
To dopiero do layoutu dołączane są pozostałe widoki jakie określamy dla danych akcji.
Widoki dołączane są do layoutu w miejscu wystąpienia:
[code]<?php echo $this->content; ?>[/code]
Rozwiązanie takie pozwala nam na modularną budowę widoków dla naszej aplikacji.
Utwórzmy teraz widok dla akcji, którą dodaliśmy akapit wyżej. Stwórzmy plik:
[code]/module/Application/view/application/index/hello.phtml[/code]
i wpiszmy w nim jako zawartość:
[code]<h1>Hello World!</h1>[/code]
Nastepnie ponownie spróbujmy wywołać akcję "hello":
[code]http://zend.localhost/application/index/hello[/code]
Jak widzimy nasza akcja została wywołana z naszym nowym widokiem:

Tworzymy własny kontroler

Umiemy już dodawać akcję do kontrolera, w takim razie dodajmy teraz całkowicie nowy kontroler, np. o nazwie "Users". Utwórzmy plik z definicją nowego kontrolera:
[code]/module/Application/src/Application/Controller/UsersController.php[/code]
o treści:
[code]
<?php
namespace Application\Controller;

use Zend\Mvc\Controller\AbstractActionController;
use Zend\View\Model\ViewModel;

class UsersController extends AbstractActionController
{
public function indexAction()
{
return new ViewModel();
}

public function profileAction()
{
return new ViewModel();
}

}[/code]
Nasz nowy kontroler będzie posiadał dwie akcje:

index - akcję domyślną wyświetlającą np. listę użytkowników
profile - akcję wyświetlającą profil danego użytkownika

Następnie utwórzmy folder z widokami dla nowego kontrolera:
[code]/module/Application/view/application/users/[/code]
a w nim dwa pliki z widokami, po jednym dla każdej z akcji:

1) /module/Application/view/application/users/index.phtml o treści:
[code]<h1>Hello World!</h1>
<h2>index - lista userów</h2>[/code]

2) /module/Application/view/application/users/profile.phtml o treści:
[code]<h1>Hello World!</h1>
<h2>profile - profil usera</h2>[/code]

Mamy już plik z definicją klasy naszego kontrolera oraz 2 pliki z widokami dla jego akcji.
Czas sprawdzić, co nam się wyświetli po wywołaniu naszego nowego kontrolera:
[code]http://zend.localhost/application/users[/code]

Niestety, ale wyświetlił nam się błąd. Dlaczego?
Ponieważ pomimo, iż mamy gotowe pliki dla kontrolera i widoku, to taki kontroler nie został dodany w konfiguracji modułu. Musimy więc tego dokonać.
Otwórzmy więc plik z konfiguracją:
[code]/module/application/config/module.config.php[/code]

i w sekcji:
[code]
'controllers' => array(
'invokables' => array(
'Application\Controller\Index' => 'Application\Controller\IndexController'
),
),[/code]
dodajmy nasz nowy kontroler:
[code]
'controllers' => array(
'invokables' => array(
'Application\Controller\Index' => 'Application\Controller\IndexController',
'Application\Controller\Users' => 'Application\Controller\UsersController'
),
),[/code]
Zapiszmy plik z konfiguracją i sprawdźmy teraz:
[code]http://zend.localhost/application/users[/code]

Bingo! Nasz kontroler działa.
Sprawdźmy jeszcze akcję dla wyświetlania profilu:
[code]http://zend.localhost/application/users/profile[/code]

I znowu bingo! Nasza druga akcja również się wyświetliła.

Podsumowanie

Na chwilę obecną umiemy więc już dodać swój własny kontroler i akcję i myślę, że to powinno wystarczyć tytułem wprowadzenia. W kolejnych artykułach będziemy działać dalej.
Mam nadzieję, że wszystko opisałem tutaj jasno i zrozumiale. Tak na marginesie - jak chyba widać Zend jest bardzo intuicyjny do opanowania i o wiele łatwiejszy w użyciu, niż np. również opisywany na tej stronie framework Symfony. Stąd też taka mała sugestia dla początkujących - jeśli dopiero zaczynamy przygodę z frameworkami, to najlepiej zacząć ją właśnie od Zenda, niż brać się od razu za wielkie i skomplikowane Symfony. I to tyle na teraz, do następnego!

[PHP][Symfony2] Instalacja i pierwsze uruchomienie Symfony2 krok po kroku

2015-06-02T16:12:00.000+02:00

Framework Symfony to jeden z najpotężniejszych frameworków napisanych dla PHP. Jest to też zarazem jeden z najpopularniejszych frameworków na świecie, warto byłoby zatem znać choćby jego podstawy. Nie jest to jednak framework łatwy w nauce, a na początku jego ogrom może nieco przytłaczać. Wszystko jednak można opanować i w cyklu artykułów tutaj postaramy się nauczyć pracy z Symfony krok po kroku. Będziemy używać wersji z gałęzi 2.x.x, gdyż wprowadza ona niesamowicie dużą ilość ilość zmian w stosunku do swoich starszych wersji, tj. wersji Legacy z gałęzi 1.x.x. Zasadniczą różnicą powiędzy wersjami 1 i 2 jest wprowadzenie zupełnie innej architektury w tej drugiej, opartej na mechaniźmie tzw. komponentów, o których oczywiście nauczymy się tutaj. Zacznijmy zatem pracę z Symfony2 i na początek pobiermy, zainstalujmy, uruchomijmy i skonfigurujmy swoje pierwsze środowisko oparte na Symfony2. Opiszę procedurę dla systemów z rodziny Windows, zakładając, że mamy zainstalowany i działający serwer Apache. Pierwsze uruchomienie Symfony dla osób nieznających tego frameworka jest nieco problematyczne, więc opiszę wszystko dokładnie krok po kroku.

Przygodę rozpoczynamy od oficjalnej strony frameworka, która znajduje się pod adresem: http://www.symfony.com. Znajdziemy tutaj informacje o najnowszej wersji, przejrzymy bazę komponentów i uzyskamy dostęp do całej dokumentacji, a ta jest naprawdę obszerna. Istnieje również polska wersja dokumentacji, dostępna pod adresem: http://symfony-docs.pl/.

Instalacja Symfony2

Stwórzmy więc sobie katalog na naszą instalację Symfony, np.:
[code]C:/www/symfony[/code]
(będę tutaj używał takiego katalogu dla przykładu, na screenach będzie to u mnie c:/www.wamp/www/symfony)

Wejdźmy teraz do naszego utworzonego katalogu z poziomu konsoli i pobierzmy małą aplikację dla Symfony, która będzie nam służyła do zarządzania projektem, wpiszmy w konsoli:
[code]$ php -r "readfile('http://symfony.com/installer');" > symfony[/code]
W tym miejscu do naszego katalogu powinien pobrać się plik "symfony", którego teraz użyjemy do inicjalizacji pierwszego projektu:
[code]$ php symfony new myApp[/code]
Pobierze nam to teraz cały pakiet Symfony2 i zainicjuje nasz projekt o nazwie "myApp".

Dla naszej aplikacji został utworzony katalog "/myApp", a w nim następująca struktura folderów:

Teraz musimy się na chwilę zatrzymać i omówić sobie strukturę katalogów w symfony.
Po pierwsze - głównym folderem dostępnym przez WWW (document rootem naszej aplikacji) będzie:
[code]/web[/code]
Do naszej aplikacji będziemy więc dostawać się tak:
[code]http://localhost/symfony/myApp/web[/code]
jednakże tutaj pojawia się mała sprawa, gdyż jedynie ten folder powinien być dostępny publicznie, wszelkie pozostałe katalogi powinny być z poziomu WWW niedostępne.
Uczynić to możemy za pomocą ustawienia sobie vhosta kierującego na katalog "/web" z naszym projektem. O tym jak utworzyć vhosta w Apache'u pisałem tutaj.
Stwórzmy więc vhosta o nazwie np.:
[code]symfony.localhost[/code]
i kierującego na:
[code]C:/www/symfony/myApp/web[/code]
tak abyśmy po wpisaniu:
[code]http://symfony.localhost/[/code]
byli kierowani wprost do tego folderu. Oczywiście jeśli tego nie zrobimy, to dostawać się do naszej aplikacji będziemy poprzez:
[code]http://localhost/symfony/myApp/web/[/code]
Polecam jednak sposób z vhostem, gdyż pozwoli nam to na zrozumienie pewnej koncepcji, która zakłada, iż powinniśmy zawsze wydzielać dostępny publicznie katalog webowy od całej reszty kodu, do której nie powinno być żadnego dostępu z zewnątrz. To jedna sprawa, druga to taka, że metoda z wirtualnym hostem jest zwyczajnie wygodniejsza podczas pracy.

Pierwsze uruchomienie

Symfony mamy już zainstalowane, zobaczmy teraz jak to działa.
Po wpisaniu w przeglądarkę adresu:
[code]http://symfony.localhost[/code]
lub jeśli nie utworzyliśmy vhosta:
[code]http://localhost/symfony/myApp/web/[/code]
który to adres prowadzi tak naprawdę do front-controllera:
[code]c:/www/symfony/myApp/web/app.php[/code]
zostaniemy na starcie przywitani brakiem dostępu.

Dzieje się tak dlatego, gdyż domyślnie pracujemy na środowisku developerskim i dostęp do środowiska produkcyjnego jest zablokowany. Na starcie mamy dostęp jedynie do środowiska developerskiego, do którego wchodzimy poprzez:
[code]http://symfony.localhost/app_dev.php[/code]

Tu wyświetli nam się błąd routingu, ale o tym za chwilę.

Symfony oczywiście pozwala na konfigurację środowiska w jakim obecnie się znajdujemy, dostępne są 3 środowiska:

dev - środowisko developerskie
prod - środowisko produkcyjne
tests - środowisko testowe

Aby móc teraz dostać się do naszego środowiska produkcyjnego, musimy w pliku:
[code]/web/app.php[/code]
zmienić linijkę:
[code]$kernel = new AppKernel('prod', false);[/code]
na
[code]$kernel = new AppKernel('prod', true);[/code]
Od tej chwili mamy dostęp do wersji produkcyjnej pod adresem:
[code]http://symfony.localhost/[/code]
a dokładnie do:
[code]c:/www/symfony/myApp/web/app.php[/code]
do którego to pliku prowadzą wszystkie requesty, co zdefiniowane jest w pliku "/web/.htaccess":
[code]RewriteRule .? %{ENV:BASE}/app.php [L][/code]

Spróbujmy teraz wejść w adres:
[code]http://symfony.localhost[/code]
Na starcie zostaniemy przywitani błędem:
[code]No route found for "GET /"[/code]

Wyjątek ten mówi nam o braku definicji dla routingu domyślnego (/), czyli dla ścieżki głównej naszej aplikacji.

Kontrolery i akcje

Aby przejść dalej i rozwiązać powyższy problem musimy nauczyć się kilku podstawowych pojęć. Otóż Symfony działa w pełnym modelu MVC, a więc jego struktura jest podzielona na warstwy modelu, kontrolera i widoku.
Do plików z definicjami naszych kontrolerów dostaniemy się w katalogu:
[code]/src/AppBundle/Controller/[/code]
Do plików widoku natomiast tutaj:
[code]/app/Resources/views/[/code]

Otwórzmy sobie dostępny domyślnie przykładowy plik controllera:
[code]/src/AppBundle/Controllers/DefaultController.php[/code]
Jego zawartość powinna wyglądać następująco:
[code]
<?php
namespace AppBundle\Controller;

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;

class DefaultController extends Controller
{
/**
* @Route("/app/example", name="homepage")
*/
public function indexAction()
{
return $this->render('default/index.html.twig');
}
}[/code]
Jak widać mamy tutaj definicję klasy kontrolera o nazwie "DefaultController".
Trzeba tutaj zrozumieć w jaki sposób działają kontrolery i routing w Symfony.
Otóż kontroler to jakaś sekcja naszej aplikacji, np. jeden kontroler może odpowiadać za obsługę kont użytkowników, inny za obsługę newsów na stronie, jeszcze inny za wyświetlanie i edycję komentarzy. Każdy taki kontroler jest podzielony na jakieś akcje, np. kontroler do obsługi użytkowników może być podzielony na akcje takie jak dodawanie użytkownika, edycja użytkownika, wyświetlanie profilu itp.
Domyślną akcją dla kontrolera jest zawsze akcja o nazwie:
[code]index[/code]
Poszczególne akcje definiujemy w klasie naszego kontrolera stosując się do składni:
[code]nazwaAction()[/code]
czyli po nazwie akcji (pisanej zawsze małymi literami, np. "edit", "add", "profile" dodajemy suffix Action.

Przykładowy kontroler do obsługi użytkowników definiujacy trzy akcje może wyglądać np. tak:
[code]
class UsersController extends Controller
{

public function addAction()
{
// [...]
}

public function editAction()
{
// [...]
}

public function profileAction()
{
// [...]
}
}[/code]

Do danej akcji musimy się jednak jakoś dostać z poziomu aplikacji, np.:
[code]http://aplikacja.com/users/add[/code]
lub
[code]http://aplikacja.com/users/profile[/code]
I tutaj do akcji wkracza tzw. routing

Routing

Konfiguracja routingu dla kontrolerów i akcji to bardzo obszerny temat i tutaj liźniemy tylko zasadę jego działania na bazie naszego przykładowego projektu.
Wróćmy do naszego domyślnego kontrolera i zobaczmy, że przed definicją metody z akcją "index" znajduje się adnotacja blokowa o treści:
[code]
/**
* @Route("/app/example", name="homepage")
*/[/code]
Określa ona trasę routingu dla akcji po tej definicji występującej.
W tym przypadku dla akcji "index" definiowany jest routing o ścieżce "/app/example".
Oznacza to, iż do definiowanej tutaj akcji dostaniemy się po wpisaniu w przeglądarce adresu:
[code]http://symfony.localhost/app/example[/code]

Dalsza część kodu, czyli definicja akcji "index":
[code]
public function indexAction()
{
return $this->render('default/index.html.twig');
}[/code]
w tym przypadku zwraca nam do wyświetlenia widok wczytywany z pliku:
[code]/app/Resources/views/default/index.html.twig[/code]
którego treść wygląda tak:
[code]
{% extends 'base.html.twig' %}

{% block body %}
Homepage.
{% endblock %}[/code]
Temat widoków to również bardzo obszerny temat, więc na razie wystarczy abyśmy wiedzieli jedynie jak to mniej więcej działa.

Wpiszmy teraz w przeglądarce:
[code]http://symfony.localhost/app/example[/code]
Jak widzimy, tym razem nie pojawił nam się już błąd związany z brakiem zdefiniowanego routingu, a wyświetlił nam się szablon zwrócony przez akcję "index" z naszego kontrolera:

Stwórzmy sobie teraz dla testu nowy plik widoku o nazwie:
[code]/app/Resources/views/default/hello.html.twig[/code]
i wpiszmy do niego:
[code]
{% extends 'base.html.twig' %}

{% block body %}
Hello World!
{% endblock %}[/code]
Następnie utwórzmy nową akcję i routing do niej w pliku:
[code]/src/AppBundle/Controllers/DefaultController.php[/code]
dopisując ją do klasy kontrolera:
[code]
<?php
namespace AppBundle\Controller;

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;

class DefaultController extends Controller
{
/**
* @Route("/app/example", name="homepage")
*/
public function indexAction()
{
return $this->render('default/index.html.twig');
}

// nasza nowa akcja
/**
* @Route("/app/hello", name="hello")
*/
public function helloAction()
{
return $this->render('default/hello.html.twig');
}
}[/code]

Dodaliśmy nową akcję, do której dostaniemy się po wpisaniu:
[code]http://symfony.localhost/app/hello[/code]
Zróbmy więc to i zobaczmy co się stanie:

Coś jest nie tak. Ale co? Otóż wszystko jest w jak najlepszym porządku, zapomnieliśmy jedynie o jednej małej rzeczy - o cache'u.

cache:clear

Symfony parsuje i cache'uje wiele elementów, aby generowały się one szybciej. W naszym powyższym przypadku dokonaliśmy zmian w strukturze szablonów dodając nowy element dla akcji "hello".
Poprzedni cache jednak tego nie uzwględnia, musimy więc wyczyścić stary cache, aby utworzyć nowy. Służy do tego skrypt:
[code]app/console[/code]
który znajdziemy w katalogu z naszą aplikacją.
Console to tak naprawdę narzędzie, którego będziemy używać często, a jego możliwości nie ograniczają się jedynie do czyszczenia cache'u.
Wejdźmy teraz w terminalu do katalogu z naszą aplikacją, czyli do:
[code]C:/www/symfony/myApp/[/code]
i z jej poziomu wywołajmy:
[code]$ php app/console cache:clear[/code]
Polecenie to wyczyści nam cache, ale uwaga - jedynie dla środowiska developerskiego.
Jeśli chcemy wyczyścić cache dla innego środowiska, np. produkcyjnego, to podajemy jego nazwę:
[code]$ php app/console cache:clear --env=prod[/code]

Po wykonaniu powyższego, czyli wyczyszczeniu folderu cache wejdźmy ponownie na:
[code]http://symfony.localhost/app/hello[/code]
Voila! Nasza dodana akcja wyświetliła się prawidłowo:

Problem z początku

Jak teraz rozwiązać problem z początku - błąd No route found for "GET /"?

Błąd ten otrzymujemy po wejściu na główną ścieżkę naszej aplikacji, czyli:
[code]http://symfony.localhost/[/code]
Otóż dokonamy małych zmian w routingu akcji "index".
Otwórzmy plik z kontrolerem:
[code]/src/AppBundle/Controllers/DefaultController.php[/code]
i dla akcji "index" zamieńmy ścieżkę routingu z:
[code]
/**
* @Route("/app/example", name="homepage")
*/[/code]
na:
[code]
/**
* @Route("/", name="homepage")
*/[/code]
Zapiszmy plik i wejdźmy ponownie na:
[code]http://symfony.localhost/[/code]
Jak widzimy - problem rozwiązany i akcja "index" wyświetliła nam się domyślnie bez podawania żadnej dodatkowej ścieżki.
Wejście tutaj poprzez środowisko developerskie da nam ponadto kilka ciekawych informacji w pasku debuggera dołączanego na dole strony:

[code]http://symfony.localhost/app_dev.php[/code]

Jak widzimy, mamy podane tutaj w jakim aktualnie kontrolerze się znajdujemy i w jakiej akcji, a także całą masę innych informacji i parametrów.

Z debuggera tego korzystać będziemy często podczas naszej pracy, podobnie jak ze skryptu "console" i czyszczenia katalogu cache, radzę się więc już na to mentalnie przygotować ;)

Podsumowanie

No i to tyle tytułem wstępu, umiemy już uruchomić Symfony i wiemy jak to wszystko mniej więcej działa. W kolejnych artykułach zaczniemy już normalną pracę z Symfony i poznamy ten framework krok po kroku. Mam nadzieję, że artykuł okazał się pomocny, gdyż szczerze mówiąc instalacja i pierwsze uruchomienie może być naprawdę problematyczne dla osoby, która z Symfony ma styczność po raz pierwszy. Dokumentacja dostępna na stronie projektu pomija kilka kluczowych rzeczy, w związku z czym początkujący użytkownik może mieć problemy już na samym starcie, mimo iż robi wszystko tak jak zostało to opisane w dokumentacji. Tutaj opisałem to absolutnie krok po kroku i pokazałem rozwiązanie, którego w takiej formie nie znajdziecie w dokumentacji. Do następnego!

[PHP][Doctrine2] Instalacja i wstęp do Doctrine2 ORM

2015-06-01T22:40:00.000+02:00

Doctrine jest systemem ORM dla relacyjnych baz danych, napisanym w PHP. ORM (Object-relational Mapping), czyli po polsku Mapowanie Obiektowo-relacyjne jest to ogólnie rzecz biorąc technika zamiany danych opisanych za pomocą obiektów w ich relacyjne modele w bazie danych. W systemach ORM pracujemy nie na rekordach z bazy, lecz na obiektach, gdyż każdy rekord reprezentowany jest jako pełnoprawny obiekt. Doctrine jest właśnie jednym z najpopularniejszych rozwiązań, które oferują takie mapowanie dla PHP. Korzystając z bibliotek Doctrine każda tabela w bazie danych prezentowana jest jako jedna wielka klasa, gdzie poszczególne rekordy (wiersze) są jej obiektami. Na obiektach takich pracujemy dokładnie tak samo jak na zwykłych obiektach, utworzonych w tradycyjny sposób. W artykule tym zainstalujemy sobie Doctrine na własnym serwerze i nauczymy się podstaw pracy z nim.

Instalacja

Instalację Doctrine zaczynamy od pobrania najnowszej wersji za pomocą Composera (tutorial dla Composera znajdziesz tutaj). Strona oficjalna z najnowszą wersją Doctrine znajduje się tutaj: http://www.doctrine-project.org/projects/orm.html
Wchodzimy na nią, sprawdzamy numerek najnowszej wersji i sporządzamy odpowiedni plik "composer.json". W tym artykule pobierzemy wersję 2.4.7, więc zawartość pliku composer.json wyglądać będzie tak:
[code]
{
"require": {
"doctrine/orm": "2.4.7"
}
}[/code]
Zapisujemy plik, np. w katalogu:
[code]C:/www/doctrine [/code]
i w terminalu (będąc w w/w wymienionym katalogu) pobieramy paczkę za pomocą biblioteki Composer:
[code]$ composer install[/code]
Pobierze nam to do folderu "/vendor" najnowszą wersję wraz ze wszystkimi wymaganymi zależnościami. Od tej chwili jesteśmy już prawie gotowi do pracy z Doctrine, zanim to jednak zrobimy przyjrzyjmy się krótkiemu opisowi jak wygląda praca z techniką ORM.

Model ORM

Jak wiemy, dane w bazie danych przechowywane są w formie rekordów, czyli wierszy, przy czym kolumny w tych wierszach reprezentują pola rekordu. Pobierając takie dane z bazy zazwyczaj otrzymujemy natomiast tablicę reprezentującą dany wiersz, w której to tablicy poszczególne pola to klucze/indeksy tej tablicy. Przykładowo, pobierając z tabeli o nazwie "customers" pola o nazwach "customer_id", "first_name" i "last_name" otrzymujemy tablicę (rekord) postaci:
[code]
$row['customer_id'];
$row['first_name'];
$row['last_name'];[/code]
W modelu ORM będzie to wyglądało nieco inaczej. Nie otrzymamy wiersza jako tablicy, lecz jako obiekt, którego właściwości będą odpowiadać polom kolumn w wierszu:
[code]
class Customer {

protected $customer_id,
protected $first_name;
protected $last_name;
[...]
}
$customer->new Customer();
[/code]
Do właściwości takich będziemy mieli dostęp za pomocą utworzonych metod getXXX(), jak np.:
[code]
$customer->getId();
$customer->getFirstName();
$customer->getLastName();
[/code]

Również tworzenie nowego rekordu w bazie nie będzie już polegało na wysłaniu do niej zapytania typu INSERT, lecz na zwyczajnym utworzeniu nowego obiektu:
[code]$customer = new Customer();[/code]
a następnie na wysłaniu obiektu do systemu ORM, który już odpowiednio przetworzy wszystko tak, aby nasz obiekt zamienić na odpowiedni rekord i umieścić go w bazie.
Analogicznie - aktualizowanie wartości pól rekordu nie będzie też już polegało na zapytaniu UPDATE, lecz na wywoływaniu odpowiednich metod obiektu, jak np.:
[code]
$customer->setFirstName($first_name);
$customer->setLastName($last_name);[/code]
Podczas pracy w modelu ORM zapomnimy całkowicie o bazie danych - wszystkie, ale to WSZYSTKIE operacje na rekordach będą odbywały się jak na zwykłych obiektach. Sposób taki więc powoduje, iż nasz kod staje się jedną wielką, zintegrowaną strukturą, w której nie musimy nagle wybijać z metodami operującymi na bazie i burzącymi pełną obiektowość kodu. Podejście takie ma całą listę zalet i chyba tylko jeden minus, którym jest konieczność ręcznego przygotowania schematu bazy i konieczność aktualizacji takiego modelu po każdorazowej modyfikacji struktury tabel. Nie jest to jednak trudne i nauczymy się tutaj tego krok po kroku. Tak na marginesie - Doctrine oferuje coś w rodzaju inżynierii wstecznej, czyli mechanizm który może na podstawie analizy struktury bazy przygotować taki model automatycznie, jednakże po pierwsze nie zawsze zadziała to tak jak jakbyśmy tego oczekiwali, a po drugie - lepiej nauczyć się przygotowywania schematu manualnie, gdyż wiedza ta będzie konieczna, jeśli chcemy pracować na poważnie.

Wiemy już na czym mniej więcej polega zasada działania, pora więc na praktykę, ale żeby stworzyć swój pierwszy projekt, musimy najpierw nauczyć się kilku podstawowych pojęć z jakich będziemy korzystać i z jakich korzysta Doctrine.

Entity

Na rodzimy język możemy to przetłumaczyć jako "byt, jednostka". Terminem Entity nazywamy w Doctrine każdy obiekt mapowany na bazę.
Każdy taki obiekt to oddzielny byt. Główną i podstawową klasą, która zarządza naszymi bytami jest w Doctrine EntityManager. Aby zrozumieć to obrazowo, spójrzmy na przykład: mając tabelę o nazwie "users" składającą się z pól:

id (int, primary index)
login (varchar 50)
password (varchar 80)

i chcąc ją zmapować jako obiekt, musimy utworzyć dla niej klasę:
[code]
<?php
// Entity
class User {

protected $id;
protected $login;
protected $password;
}
?>[/code]
To co powyżej to właśnie nasz "Entity", czyli obiekt mapowany na bazę danych.
Widzimy tutaj, że został on opisany za pomocą definicji klasy zwykłym kodem PHP, ale w Doctrine możemy użyć do opisu także XML i YAML-a.

W XML-u nasz Entity opisany będzie tak:
[code]
<doctrine-mapping>
<entity name="User">
<field name="id" type="integer" />
<field name="login" length="50" name="login" />
<field name="password" length="80" />
</entity>
</doctrine-mapping>[/code]

A w YAML-u tak:
[code]
User:
type: entity
fields:
id:
type: integer
login:
length: 50
name: login
password:
length: 80[/code]

W PHP podałem powyżej jedynie obrazowy przykład, właściwy opis bytu wyglądałby tak:
[code]
<?php
/** @Entity */
class User {

/** @Column(type="integer") */
protected $id;
/** @Column(length=50, name="login") */
protected $login;
/** @Column(length=80) */
protected $password;
}
?>[/code]
Te dodatkowe pola z opisami właściwości danej kolumny wyglądające na zwykłe komentarze blokowe to adnotacje docblock i są one odczytywane i przetwarzane przez Doctrine.

Właściwości mapowanych kolumn

Właściwości opisujących dane pole jest oczywiście więcej:

type - typ kolumny, np. "integer", domyślnie: string.
name - nazwa kolumny w bazie, domyślnie: nazwa taka sama jak deklaracja - UWAGA: W przypadku nazwy będącem słowem kluczowym ujmujemy w cytat: `name`
length - jeśli pole jest typu string to określa jego długość, domyślnie: 255
unique - określa, czy pole posiada unikalny klucz, domyślnie: false
nullable - czy kolumna może przyjąć NULL, domyślnie: false
precision - precyzja dla liczb dziesiętnych, czyli maksymalna liczba wszystkich cyfr dziesiętnych, domyślnie: 0
scale - precyzja dla liczb dziesiętnych, ale tylko dla wartości po przecinku, domyślnie: 0, nie może być większa niż określona w "precision"
columnDefinition - własna definicja wykonywana podczas tworzenia kolumny, np. "CHAR(3) NOT NULL"
options - dodatkowe opcje podawane na zasadzie "klucz-wartość"

Jeśli nie określamy typu pola ręcznie to przyjmowane jest, że jest ono typu string, czyli standardowy VARCHAR w bazie.

Mapowane typy kolumn

Typy kolumn dostępne w Doctrine to:
(podaję nazwę typu dla PHP i odpowiednik w bazie SQL)

string - mapuje VARCHAR w SQL na string w PHP
integer - mapuje INT w SQL na integer w PHP
smallint - mapuje SMALLINT w SQL na integer w PHP
bigint - mapuje BIGLLINT w SQL na integer w PHP
boolean - mapuje TINYINT/boolean w SQL na boolean w PHP
decimal - mapuje DECIMAL w SQL na string w PHP
date - mapuje DATETIME w SQL na obiekt DateTime w PHP
time - mapuje TIME w SQL na obiekt DateTime w PHP
datetime - mapuje DATETIME/TIMESTAMP w SQL na obiekt DateTime w PHP
datetimetz - mapuje DATETIME/TIMESTAMP w SQL na obiekt DateTime ze strefą czasową w PHP
text - mapuje CLOB w SQL na string w PHP
object - mapuje CLOB w SQL na obiekt w PHP, z użyciem serialize() i unserialize()
array - mapuje CLOB w SQL na tablicę w PHP, z użyciem serialize() i unserialize()
simple_array - mapuje CLOB w SQL na tablicę w PHP, z użyciem implode() i explode(), rozdzialając przecinkiem (,)
json_array - mapuje CLOB w SQL na tablicę w PHP, z użyciem json_encode() i json_decode()
float - mapuje FLOAT w SQL na double w PHP (wymagana kropka jako separator części po przecinku)
guid - mapuje GUID/UUID w SQL na string w PHP
blob - mapuje BLOB w SQL na resource w PHP

Identyfikator

Określa on klucz podstawowy dla tabeli w bazie danych. Jego zdefiniowanie jest wymagane.
Klucz podstawowy denifiujemy następująco:

PHP:
[code]
<?php
/** @Entity */
class User {
/**
* @Id @Column(type="integer")
* @GeneratedValue(strategy="AUTO")
*/
protected $id;
//[...]
}
?>[/code]

XML:
[code]
<doctrine-mapping>
<entity name="User">
<id name="id" type="integer">
<generator strategy="AUTO" />
</id>

</entity>
</doctrine-mapping>[/code]

YAML:
[code]
User:
type: entity
id:
id:
type: integer
generator:
strategy: AUTO
fields:
# [...][/code]

Podczas definicji identyfikatora możemy określić sposób w jaki wartość ma być inkrementowana, do czego służy wyżej widoczny parametr GENERATOR STRATEGY.
Możliwe do ustawienia wartości to: auto (domyślnie), sequence, identity i none. Więcej o nich napiszę w pozostałych artykułach.

Próba ognia

Opiszę teraz dokładnie krok po kroku, co zrobić, żeby wszystko nam zadziałało, gdyż trzeba tutaj wykonać kilka manewrów, podczas których niedoświadczeni z Doctrine mogliby coś pominąć. Zwłaszcza, że w oficjalnym poradniku jest to wszystko opisane trochę nie po kolei. Na początek musimy stworzyć sobie jeden folder i trochę usprawnić swoją instalację Doctrine - a użyjemy do tego Composera.

Krok 1 - tworzymy katalog na definicje Entities

Stwórzmy folder o nazwie:
[code]c:/www/doctrine/src/Model[/code]
W folderze tym zapiszemy pliki z deklaracjami naszych Entities, które wykorzysta Doctrine.

Krok 2 - modyfikujemy composer.json i aktualizujemy autoloader

Następnie zmodyfikujmy lekko plik:
[code]C:/www/doctrine/composer.json[/code]
zmieniając jego zawartość na:
[code]
{
"require": {
"doctrine/orm": "2.4.7",
"symfony/yaml": "*"
},
"autoload": {
"psr-0": {"": "src/Model/"}
}
}[/code]
gdzie w miejsce wersji Doctrine podajmy tą, którą pobieraliśmy na początku.
Powyższy wpis spowoduje, że doinstalujemy sobie obsługę plików YAML, a także zmodyfikujemy lekko autoloader Composera, tak aby uwzględniał nam pliki z katalogu "/src/Model", czyli katalogu, w którym zapiszemy pliki z deklaracjami Entities. Bez tego manewru napotkalibyśmy w kolejnych krokach na błąd mówiący o braku definicji klasy.

Mając tak zmodyfikowany "composer.json" wchodzimy teraz do konsoli/terminala i z poziomu katalogu:
[code]C:/www/doctrine/[/code]
wpisujemy:
[code]$ composer update[/code]
Doinstaluje nam to pakiet YAML i zaktualizuje autoloader.

Krok 3 - tworzymy definicję prostego obiektu Entity

Stwórzmy teraz sobie prosty obiekt mapujący tabelę "users".
Utwórzmy zatem plik:
[code]C:/www/doctrine/src/Model/User.php[/code]
i jako jego zawartość wklejmy:
[code]
<?php
// /src/Model/User.php
/**
* @Entity @Table(name="users")
**/
class User {

/**
* @Id @Column(type="integer")
* @GeneratedValue(strategy="AUTO")
*/
protected $id;

/** @Column(length=50, name="login") */
protected $login;

/** @Column(length=80) */
protected $password;

public function getId()
{
return $this->id;
}

public function getLogin()
{
return $this->login;
}

public function setLogin($login)
{
$this->login = $login;
}

public function getPassword()
{
return $this->password;
}

public function setPassword($password)
{
$this->password = $password;
}
}[/code]
Będzie to definicja obiektu, który będziemy mapować na tabelę "users".
Definiujemy tutaj 3 pola: id, login i password oraz metody getXXX() i setXXX() dla tych pól.
Zauważmy, że dla pola $id nie definiujemy metody setId(). Mając tak przygotowaną konfigurację prostego bytu lecimy dalej.
Zauważmy też, iż definiujemy nazwę tabeli jako "users" mimo iż nazwa klasy to User.

Krok 4 - bootstrap.php

Tworzymy teraz plik:
[code]C:/www/doctrine/bootstrap.php[/code]
i wpisujemy mu taką zawartość:
[code]
<?php
// bootstrap.php
// Dołączamy autoloader Composera
require_once "/vendor/autoload.php";

// Określamy przestrzenie nazw z jakich skorzystamy
use Doctrine\ORM\Tools\Setup;
use Doctrine\ORM\EntityManager;

// określamy ścieżkę do plików z Entities
$paths = array(__DIR__.'/src/Model');

// informujemy, że pracujemy w środowisku developerskim, a nie na produkcji
$isDevMode = true;

// konfigurujemy dostęp do bazy
$dbParams = array(
'driver' => 'pdo_mysql',
'user' => 'root',
'password' => '',
'dbname' => 'doctrine_test',
);

// konfigurujemy Doctrine
$config = Setup::createAnnotationMetadataConfiguration($paths, $isDevMode);
$entityManager = EntityManager::create($dbParams, $config);
?>[/code]

Krok 5 - index.php

Tworzymy teraz plik:
[code]C:/www/doctrine/index.php[/code]
i includujemy w nim plik bootrstrapa:
[code]
<?php
// index.php
require_once(__DIR__.'/bootstrap.php');
?>[/code]
Czemu taki układ? Po to, żebyśmy przyzwyczaili się do używania plików bootstrap i to w nich trzymali kod. Plik bootstrap tak w ogóle powinniśmy umieścić w innym miejscu, ale na potrzeby próby z Doctrine nie jest to teraz ważne. Napiszę o tym kiedyś artykuł, na razie niech to po prostu pozostanie w takiej formie.

Krok 6 - generujemy tabelę

Doctrine jeśli może juz zauważyliśmy, do katalogu /vendor/bin pobrał nam kilka użytecznych narzędzi. Będziemy z nimi pracować później, podczas normalnej pracy.
Wykorzystamy je także teraz, ale najpierw musimy utworzyć plik:
[code]C:/www/doctrine/cli-config.php[/code]
w którym wpisujemy dwie poniższe linijki:
[code]
<?php
// cli-config.php
require_once "bootstrap.php";
return \Doctrine\ORM\Tools\Console\ConsoleRunner::createHelperSet($entityManager);[/code]

Tworzymy teraz bazę danych do jakiej parametry podaliśmy w pliku "bootstrap.php" i NIE TWORZYMY w niej żadnych tabel.
Następnie z poziomu naszego katalogu wpisujemy w terminalu:
[code]$ "vendor/bin/doctrine" orm:schema-tool:create[/code]
Uruchomi nam to narzędzie z pakietu Doctrine służące do operacji na bazie danych, w tym przypadku wygeneruje nam ono tabelę opartą na naszym Entity opisanym w pliku "User.php".

Narzędzia tego będziemy zresztą używać później w celu aktualizacji struktury bazy podczas edycji naszego obiektu.

Krok 7 - dodajemy rekord za pomocą ORM

Jeśli wykonaliśmy już wszystkie poprzednie kroki, jesteśmy gotowi do pierwszej operacji za pomocą Doctrine.
Wróćmy do pliku "bootrstrap.php" i dopiszmy na jego końcu to co poniżej:
[code]
// tworzymy nowy obiekt
$user = new User();
$user->setLogin('janusz');
$user->setPassword('12345');

$entityManager->persist($user); // mówimy Doctrine, że tworzymy nowy obiekt
$entityManager->flush(); // wykonujemy zapis do bazy

echo "Dodano usera o id: " . $user->getId() . "\n";[/code]
Jak widać tworzymy tutaj nowy obiekt, ustawiamy mu dwie właściwości - login oraz password, a następnie zachowujemy go w bazie.
Metoda $entityManager->persist() odpowiada w Doctrine za umieszczenie rekordu w bazie, ale jeszcze nie wykonywania zapytania do niej.
Do bazy nasz obiekt leci dopiero w momencie wykonania metody $entityManager->flush(). Skąd taka konstrukcja? Otóż tutaj mamy jedynie prosty kod odpowiadający za dodanie raptem 1 rekordu, natomiast w całej aplikacji tego kodu może być bardzo dużo. W przypadku takim wykonanie metody flush() dopiero na samym końcu spowoduje, że wszystkie zapytania jakie zebrał w całym kodzie Doctrine zostaną objęte jedną transakcją i dopiero wykonane, co zwiększy wydajność i zmniejszy czas połączenia z serwerem bazy.

Dołączmy zatem powyższy kod do bootstrapa:
[code]
<?php
// bootstrap.php
// Dołączamy autoloader Composera
require_once "/vendor/autoload.php";

// Określamy przestrzenie nazw z jakich skorzystamy
use Doctrine\ORM\Tools\Setup;
use Doctrine\ORM\EntityManager;

// określamy ścieżkę do plików z Entities
$paths = array(__DIR__.'/src/Model');

// informujemy, że pracujemy w środowisku developerskim, a nie na produkcji
$isDevMode = true;

// konfigurujemy dostęp do bazy
$dbParams = array(
'driver' => 'pdo_mysql',
'user' => 'root',
'password' => '',
'dbname' => 'doctrine_test',
);

// konfigurujemy Doctrine
$config = Setup::createAnnotationMetadataConfiguration($paths, $isDevMode);
$entityManager = EntityManager::create($dbParams, $config);

// tworzymy nowy obiekt
$user = new User();
$user->setLogin('janusz');
$user->setPassword('12345');

$entityManager->persist($user); // mówimy Doctrine, że tworzymy nowy obiekt
$entityManager->flush(); // wykonujemy zapis do bazy

echo "Dodano usera o id: " . $user->getId() . "\n";
?>[/code]
Następnie wejdźmy na:
[code]http://localhost/doctrine/index.php[/code]

Jeśli wszystko się udało to właśnie dodaliśmy swój pierwszy obiekt do bazy za pomocą Doctrine'a:

Jak widać, mimo kilku niezbędnych kroków jakie wykonać trzeba podczas rozpoczęcia pracy z Doctrine całość nie jest bardzo skomplikowana.
Schodki zaczną się jednak później, gdyż Doctrine to naprawdę potężna i złożona biblioteka, której opanowanie zajmie trochę czasu. Mam jednak nadzieję, że w kolejnych artykułach omówimy sobie i przeanalizujemy wszystko dokładnie krok po kroku. Na chwilę obecną znamy podstawy i umiemy już dołączyć Doctrine do projektu, więc myślę, że tyle tytułem wstępu powinno na teraz wystarczyć.

[PHP][Smarty] Instalacja i wstęp do Smarty

2015-05-31T23:22:00.002+02:00

Smarty to chyba najpopularniejszy system szablonów jaki istnieje do PHP. Rozwijany przez lata doczekał się już jakiś czas temu swojej 3 wersji. Smarty pozwala na całkowite rozdzielenie warstwy prezentacyjnej aplikacji od jej warstwy logiki. Rozbudowywany przez lata dorobił się naprawdę ogromu funkcji możliwości. W artykule tym zobaczymy w jaki sposób zainstalować silnik Smarty w swojej aplikacji oraz jak w podstawowy sposób z niego korzystać. Taka podstawowa wiedza pozwoli na zapoznanie się z systemem i umożliwi dalszą naukę tego co Smarty oferuje, a oferuje naprawdę bardzo wiele. Dzięki Smarty całkowicie oddzielimy warstwę prezentacji naszej aplikacji i zgodnie ze wzorcem MVC w pełni odseparujemy ją od reszty aplikacji. Na początek może krótkie wprowadzenie do tego czym jest i jak powinien być rozumiany wzorzec MVC. Nazwa tego wzorca to skrót od Model-View-Controller, a więc Model-Prezentacja-Kontroler. Jest to ogólnie przyjęty wzorzec projektowania aplikacji, który rozdziela ją na 3 niezależne, ale współpracujące ze sobą warstwy. Warstwa modelu odpowiada za wszystkie dane jakie przetwarza aplikacja, zarządza dostępem do bazy i zajmuje się przetwarzaniem wszystkich elementów z którymi pracuje aplikacja. Warstwa prezentacyjna odpowiada za wyświetlanie przetwarzanych przez warstwę modelu danych użytkownikowi i za interfejs komunikacji z nim. Warstwa kontrolera natomiast steruje tym wszystkim i zarządza aplikacją określając sposób w jaki przetwarzane w modelu dane przekazać użytkownikowi w warstwie prezentacji. Wzorzec bardzo praktyczny, efektywny i traktowany już obecnie jako standard w projektowaniu aplikacji. Smarty pracować bedzie w drugiej z omówionych warstw - a więc prezentacyjnej.

Instalacja

Instalacja Smarty sprowadza się do pobrania bibliotek składających się na silnik oraz dołączeniu ich do własnej aplikacji. Najnowszą wersję pakietu pobierzemy zawsze z oficjalnej strony: http://www.smarty.net/. W dziale download znajdziemy link do repozytorium na GitHUB-ie, które następnie pobierzemy sobie na dysk. Pobierzmy zatem Smarty w wersji spakowanej zipem: https://github.com/smarty-php/smarty/archive/master.zip
Pod tym linkiem znajduje się zawsze najnowsza, stabilna wersja biblioteki Smarty.
Możemy też odwiedzić repozytorium bezpośrednio: https://github.com/smarty-php/smarty
Jeśli natomiast chcemy pobrać bibliotekę za pomocą GIT-a, to link do sklonowania repozytorium wygląda tak:
[code]git clone https://github.com/smarty-php/smarty.git[/code]

Smarty możemy także pobrać za pomocą Composera - pisałem o tym w tym artykule, przy okazji omówienia podstaw obsługi Composera. Aby zainstalować z poziomu Composera, tworzymy plik "composer.json" w folderze, gdzie chcemy pobrać Smarty o treści:
[code]
"require": {
"smarty/smarty": "~3.1"
}[/code]
Następnie uruchamiamy Composera i instalujemy:
[code]$ composer install[/code]

Zaczynamy

Niezależnie, którego sposobu użyliśmy, trafiły do nas te same pliki.
Rozpakujmy pobrane archiwum (jeśli pobraliśmy plik .zip) i skopiujmy zawarty w archiwum katalog:
[code]/libs[/code]
do katalogu z naszym projektem, np.
[code]C:/www/smarty/libs[/code]
(będę się tu posługiwał takim przykładem, gdzie "C:/www" to Document Root webserwera)
W katalogu "/libs" znajdują się wszystkie potrzebne dla nas biblioteki.

Jeśli chcemy zobaczyć Smarty w działaniu to skopiujmy również katalog "/demo" i zobaczmy:
[code]http://localhost/smarty/demo/[/code]

Teraz, aby móc zacząć pracę ze Smarty musimy utworzyć trzy podkatalogi w katalogu z naszym projektem:

C:/www/smarty/templates
C:/www/smarty/templates_c
C:/www/smarty/cache

Muszą mieć one uprawnienia do zapisu przez PHP, co na Windowsach nie wymagać będzie żadnych zabiegów, ale już na Linuxach trzeba tym katalogom ustawić:
[code]chmod 775[/code]

W folderach:

/templates - trzymać będziemy nasze szablony w postaci plików .tpl
/templates_c - tutaj trzymane będą skompilowane do kodu PHP wersje szablonów
/cache - trzymany tu będzie finalnie wygenerowany i skompilowany przez Smarty widok

Jak widać po samej strukturze folderów - Smarty kompiluje szablony do wersji z normalnym kodem PHP. Dzięki temu biblioteka działa szybciej, gdyż nie musi za każdym razem parsować od nowa tego samego szablonu, a jedynie podstawić zmienne do wersji skompilowanej.

Pierwszy projekt

Stworzymy sobie teraz pierwszy projekt z użyciem Smarty i zobaczymy jak to mniej więcej działa.
Utwórzmy plik:
[code]C:/www/smarty/index.php[/code]
tak, aby mieć do niego dostęp z poziomu:
[code]http://localhost/smarty/index.php[/code]
i dołączmy do niego bibliotekę Smarty:
[code]
<?php
/* index.php */

require '/libs/Smarty.class.php';
$smarty = new Smarty;
?>[/code]
Będzie to nasz główny plik z kodem PHP.
Następnie utwórzmy prosty plik z szablonem strony:
[code]C:/www/smarty/templates/index.tpl[/code]
I jako zawartość wklejmy mu prosty kod HTML:
[code]
<html>
<head>
<title>Smarty</title>
</head>

<body>
<h1>Testujemy Smarty</h1>
</body>
</html>[/code]
(pamiętajmy o rozszerzeniu - plik mówi mieć końcówkę .tpl, a nie .php)

Mamy już dwa bazowe pliki, których będziemy tutaj używać, zobaczmy teraz na jakiej zasadzie działa Smarty.

Po stronie kodu - index.php

W pliku "index.php" znajdować się będzie cały kod z jakiego składać się będzie nasza prosta, przykładowa aplikacja. Kod ten nie będzie wyświetlać żadnych danych, będzie jedynie je generować i przetwarzać. Wszelkie dane jakie będą miały być wyświetlone na ekranie zostaną z poziomu tego pliku wysłane do silnika Smarty, który następnie przetworzy nasz szablon (znajdujący się w pliku .tpl) i podstawi do niego wygenerowane przez naszą aplikację dane, a następnie taki szablon - uzupełniony o nasze dane wyświetlli na ekranie. Skąd jednak Smarty ma wiedzieć co i gdzie ma wyświetlić? Musimy mu o tym powiedzieć, a zrobimy to za pomocą metody:
[code]$smarty->assign('nazwa', $zmienna);[/code]
Metoda assign() przypisuje zmienne do szablonu i mówi silnikowi Smarty, aby w miejscu w szablonie, które zostanie oznaczone znacznikiem nazwa wstawić wartość zmiennej $zmienna.

Po stronie szablonu - /templates/index.tpl

W pliku "index.tpl" nie znajdzie sie ani jedna linijka kodu PHP. Zamiast tego, w miejscach, gdzie mają wyświetlić się dane generowane przez PHP wstawimy odpowiednie znaczniki z nazwami.
Znacznik taki będzie miał w szablonie postać:
[code]{$nazwa_znacznika}[/code]
Jak więc widzimy, znacznik to nazwa ze znakiem dolara objęta w nawiasy klamrowe.
Nazwę tę definiujemy podczas przypisania zmiennej w pliku "index.php" metodą $smarty->assign().

I tak na przykład:
[code]$smarty->assign('site_title', $title);[/code]
czyli przypisanie wykonane w kodzie w pliku "index.php", spowoduje, że w pliku "index.tpl", w miejscu gdzie wystąpi znacznik:
[code]{$site_title}[/code]
wyświetlona zostanie wartość zmiennej $title.

Zobaczmy to na prostym przykładzie:
Plik "index.php":
[code]
<?php
/* index.php */
// dołączamy bibliotekę Smarty
require '/libs/Smarty.class.php';
$smarty = new Smarty;

// tworzymy zmienne
$title = 'Smarty test';
$time = date('H:i:s');
$text = 'Hello World!';
$footer = 'a to stopka';

// przypisujemy zmienne do szablonu
$smarty->assign('site_title', $title);
$smarty->assign('time', $time);
$smarty->assign('text', $text);

$smarty->display('index.tpl');
// renderujemy widok z szablonu index.tpl
?>[/code]

Teraz w pliku "/templates/index.tpl":
[code]
<html>
<head>
<title>{$site_title}</title>
</head>

<body>
<h2>{$text}/h2>
Obecna godzina to: {$time}
<br /><br />
{$footer}
</body>
</html>
[/code]
Zapisujemy pliki i wchodzimy na:
[code]http://localhost/smarty/index.php[/code]

Wyświeti nam się:

Zaglądając w źródło zobaczymy, że jest to dokładnie nasz szablon wypełniony odpowiednimi zmiennymi:
[code]<html>
<head>
<title>Smarty test</title>
</head>

<body>
<h2>Hello World!</h2>
Obecna godzina to: 22:52:10
<br /><br />
a tutaj stopka
</body>
</html>[/code]

I to tyle tytułem podstawowego wprowadzenia do Smarty.
Wiemy już jak mniej więcej to działa, więc w kolejnych artykułach zajmiemy się dalszymi kwestiami i już normalną pracą ze Smarty.

[PHP][Composer] Instalacja i podstawy używania Composera

2015-05-31T19:36:00.001+02:00

Composer to popularna aplikacja do obsługi zależności pomiędzy bibliotekami w zadanych projektach. Na czym to polega? Otóż pracując nad swoim projektem bardzo często wykorzystujemy jakieś biblioteki i komponenty osób trzecich. Przykładowo - pisząc aplikację korzystającą z ORM Doctrine do obsługi bazy nasza aplikacja jest zależna od tej właśnie biblioteki i wymaga jej do poprawnej pracy. Bibliotekę oczywiście możemy na stałe dołaczyć do naszego projektu, ale jest to rozwiązanie nieeleganckie. Z pomocą przychodzi właśnie Composer - wystarczy, że spreparujemy odpowiedni plik z informacją dla Composera, w której opiszemy od jakich zewnętrznych bibliotek zależny jest nasz projekt i jakich wymaga do poprawnego działania. Composer następnie podczas instalacji naszej aplikacji odczyta nasz plik z opisem zależności, pobierze je i umieści w naszym projekcie. Takie zewnetrzne biblioteki zazwyczaj lądują w katalogu /vendor. Co najlepsze - Composer pobierze także zależności dla bibliotek, od jakich zależna jest nasza aplikacja - bo trzeba zauważyć, że może się zdarzyć, że korzystamy z zewnętrznej biblioteki, która do swojego działania wymaga jeszcze innej zewnętrznej biblioteki. Composer wszystko to automatycznie uwzgledni.

Z Composera korzysta wiele dużych projektów, np. instalując framework Symfony instalujemy go właśnie za pomocą Composera. Jego instalacja w systemie jest prosta i sprowadza się do kilku kroków. Opiszę poniżej sposób instalacji w systemach z rodziny Windows. W Windowsie możemy to zrobić na dwa sposoby - pobierając instalator, który zrobi wszystko za nas, lub manualnie - za pomocą terminala. Opiszę drugi sposób, żeby pokazać jak Composer wygląda "od środka".
Jeśli jednak chcemy to zrobić to automatycznie, to podaję link do instalatora: https://getcomposer.org/Composer-Setup.exe

Oficjalna strona Composera to: https://getcomposer.org/

Instalacja manualna

Zainstallujemy Composera manualnie. Pozwoli nam to zobaczyć czym tak naprawdę jest Composer.
Do zainstalowania wymagane jest PHP w wersji conajmniej 5.3.2 więc zakładam, że takową lub wyższą wersję już posiadamy. Pierwszym krokiem jest wejście w terminal, utworzenie folderu w którym Composera chcemy zainstalować i z poziomu tego folderu wykonanie komendy:
[code]$ php -r "readfile('https://getcomposer.org/installer');" | php[/code]

Pobierze nam to Composera do katalogu, w którym się znajdujemy.
Po instalacji dopisujemy ścieżkę do folderu z Composerem do zmiennej PATH:

Dopisujemy tutaj na końcu po średniku ścieżkę do katalogu z Composerem, zatwierdzamy i ponownie uruchamiamy terminal (terminal odczytuje zmienną PATH tylko raz podczas uruchomienia).
Następnie w katalogu z Composerem tworzymy plik:
[code]composer.bat[/code]
i wpisujemy do niego:
[code]echo @php "%~dp0composer.phar" %*>composer.bat[/code]
Mając już dodaną ścieżkę i pobranego Composera sprawdźmy, czy wszystko działa poprawnie, wpisujac w terminalu:
[code]$ composer -V[/code]
Powinna nam się wyświetlić informacja o aktualnie zainstalowanej wersji Composera:

Jak widzimy w katalogu - Composer to jeden plik o nazwie:
[code]composer.phar[/code]
Czym jest PHAR? Otóż PHAR jest to spakowane archiwum z aplikacją napisaną w PHP. Możemy tworzyć takie archiwa sami pakując nasze aplikacje do tego typu archiwum, ale o tym w innym artykule. Taki plik jest normalnie uruchamiany i wykonywany przez interpreter PHP za pomocą komendy:
[code]$ php achiwum_z_aplikacją.phar[/code]

Konfiguracja - composer.json

Wróćmy jednak do naszego Composera. Mamy już zainstalowaną aplikację, pora teraz na wytłumaczenie kilku spraw odnośnie używania Composera. Po pierwsze - tak jak to zostało wspomniane na wstępie - dla Composera musi zostać przygotowany specjalny plik, który określi mu listę zależności jakie należy pobrać i doinstalować. Plik taki przygotowujemy w formacie JSON i umieszczamy w katalogu z aplikacją, dla której chcemy pobrać zależne biblioteki. Nazwa takiego pliku to zawsze:
[code]composer.json[/code]
a jego zawartość wygląda tak:
[code]
{
"require": {
"dostawca/nazwa_aplikacji": "wersja_aplikacji"
}
}[/code]

Przykładowo, jeśli chcemy zawrzeć tutaj np. pakiet Smarty, który chcemy dołączyć do naszej aplikacji - podać możemy:
[code]
{
"require": {
"smarty/smarty": "3.1.19"
}
}[/code]
co oznaczać będzie dokładnie to: moja aplikacja wymaga do działania biblioteki "smarty" od dostawcy o nazwie "smarty" w wersji "3.1.19".

Instalacja zależności - composer install

Sprawdźmy teraz to w praktyce. Utwórzmy katalog o nazwie "smarty" i wejdźmy do niego w terminalu.
W katalogu tym umieśćmy plik "composer.json" o treści:
[code]
{
"require": {
"smarty/smarty": "~3.1"
}
}[/code]
(przed cyfrą 3 znajduje się znak tyldy jeśli jest to mało widoczne)
Następnie wykonajmy polecenie:
[code]$ composer install[/code]
które pobierze i zainstaluje nam tutaj pakiet Smarty w najnowszej dostępnej wersji z gałęzi 3.1.x:

Możemy też przekopiować plik "composer.phar" do tego katalogu i wykonać go poleceniem:
[code]$ php composer.phar install[/code]

Zobaczmy teraz w naszym folderze - jeśli wszystko poszło dobrze to Smarty zostało zainstalowane do katalogu /vendor:

Przy okazji, jak widzimy - utworzył się nam tam też plik:
[code]autoload.php[/code]
o treści mniej więcej takiej:
[code]
<?php

// autoload.php @generated by Composer

require_once __DIR__ . '/composer' . '/autoload_real.php';

return ComposerAutoloaderInit9ff9d8a01182b790e18358de1f571cba::getLoader();[/code]

Autoładowanie klas - autoload.php

Composer jak widzimy automatycznie tworzy plik autoładujący dołączane biblioteki! Nie musimy więc martwić się o odpowiednie dołączanie pobieranych bibliotek, wystarczy teraz, że w naszym projekcie podamy jedynie ścieżkę do autoloadera stworzonego przez Composera:
[code]
<?php
require __DIR__ . '/vendor/autoload.php';
?>[/code]
a całą resztę - związaną z załadowaniem odpowiednich klas wykona już za nas on sam, a konrektnie plik autoload.php przez niego wygenerowany. Jest to bardzo fajna i przydatna funkcjonalność Composera. Oczywiście nic nie stoi na przeszkodzie, aby korzystać z własnego autoloadera, Composer niczego tutaj na nas nie wymusza, a jedynie oferuje funkcjonalność z której jeśli chcemy to możemy skorzystać.

Wersjonowanie

Pobierając pakiet Smarty podaliśmy w pliku "composer.json" następującą nazwę wymaganej wersji:
[code]~3.1[/code]
(z tyldą na początku)

W Composerze możemy określić nazwę wymaganej wersji wg kilku odpowiednich wytycznych. Służy do tego odpowiednia składnia, która wygląda następująco:

1.0.0 - określa, że wymagana jest DOKŁADNIE wersja 1.0.0
>=1.0 - określa, że wymagana jest wersja conajmniej 1.0, w przypadku istnienia wersji nowszej od 1.0 Composer pobierze najnowszą dostępną wersję
>=1.0 < 2.1 - określa, że wymagana jest wersja conajmniej 1.0, ale mniejsza niż 2.1
1.0 - 3.0 - określa, że interesuje nas wersja z przedziału od 1.0 do 3.0
1.0.* - określa, że interesuje nas wersja z przedziału od 1.0.x do 1.1.0
~1.3 - określa, że interesuje nas wersja z przedziału 1.3, ale mniejsza od następnego końcowego numerka, czyli 1.4, np. 1.3.1, 1.3.5, 1.3.9,
^1.3 - określa, że intersuje nas wersja większa lub równa 1.3, ale mniejsza od następnego początkowego numerka, czyli 2.0, np. 1.3, 1.8, 1.9.9

Composer zasze pobiera najnowszą aktualnie dostępną wersję z zadanego przedziału, lub konkretnie tą jedną wymaganą, jeśli zamiast przedziału podajemy dokładny numer wersji.

Blokada wersji - composer.lock

W katalogu do którego pobieraliśmy Smarty jak może już zauważyliśmy utworzył się jeszcze jeden plik - "composer.lock".
Warto wiedzieć do czego on słuzy. Otóż w pliku tym Composer zapisuje informacje o aktualnie pobranych tutaj zależnościach (w naszym przypadku - Smarty) i ich dokładnych wersjach.
Wyobraźmy sobie teraz, że hostujemy nasz projekt jako repozytorium na GitHUB-ie, do którego ma dostęp cała masa innych programistów. Programista taki klonuje sobie nasze repozytorium, instaluje do niego wymagane zależności dzięki plikowi composer.js, który mówi mu jakie zależności pobrać należy i nagle okazuje się, że otrzymuje do pracy lekko odmienną wersję. Dlaczego?

Ponieważ np. w pliku "composer.json" określiliśmy, iż nasza aplikacja wymaga do pracy danej biblioteki w wersji conajmniej 1.1 i taka też najnowsza wersja była dostępna w momencie commitowania repozytorium. Godzinę później natomiast dostawca naszej zależności wypuszcza wersję 1.2, która od tej pory staje się najnowszą dostępną wersją. Programista jaki teraz pobierze nasze repozytorium i instalując zależności przez Composera otrzyma już nie wersję 1.1, a wersję 1.2. I do prewencji przed takim czymś służy właśnie plik "composer.lock".

Określa on, jaka jest aktualna wersja zależności na której obecnie pracujemy. Jeśli teraz w pliku "composer.lock" mamy zapisaną informację, iż w momencie wysyłania repozytorium pracujemy z wersją 1.1 zależnej biblioteki, to programista klonujący nasze repozytorium otrzyma od Composera właśnie taką wersję, a my będziemy mieli pewność, że osoba, która teraz pracuje z naszym repozytorium pracuje na DOKŁADNIE takiej samej wersji plików jak my. Dlatego pamiętajmy o tym, aby podczas commita zawsze wysyłać do repozytorium również plik "composer.lock".

Aktualizacja zależności - composer update

Aktualizacji do nowszej wersji danej zależności (o ile taka wyszła) dokonujemy za pomocą:
[code]$ composer update[/code]
W przypadku nowszych wersji, niż ta którą posiadamy wyświetli się nam po prostu komunikat "Nothing to update":

Jeśli natomiast pojawila się nowsza wersja (np. Smarty w naszym przypadku) to Composer ją pobierze i zaktualizuje nam bibliotekę do nowszej wersji. Jeśli natomiast korzystamy z kilku zależności, a chcemy zaktualizować tylko jedną, lub kilka określonych podajemy je po spacji za komendą update, np.:
[code]$ composer update smarty/smarty inna/inna jeszcze_inna/jeszcze_inna[/code]

Jak widzimy, Composer to bardzo fajne i pomocne narzędzie. Za takim stwierdzeniem świadczyć powinien choćby fakt, iż wszystkie większe projekty korzystają z jego dobrodziejstw. Zapoznanie się z nim jest więc czasem wręcz konieczne. Mam nadzieję, że dzięki temu wpisowi umiecie już w podstawowy korzystać z Composera. W następnym artykule opiszę w jaki sposób utworzyć i udostępnić swoją własną paczkę, tak aby można ją było pobrać poprzez wpis w "composer.json".

[PHP] Kiedy cudzysłów, a kiedy apostrof

2015-05-31T19:12:00.000+02:00

...czyli różnica pomiędzy cudzysłowem, a apostrofem.

W PHP, jak i we właściwie każdym języku wszelkie zmienne typu string obejmować musimy w cudzysłowy, lub apostrofy. Mamy tutaj dowolność, jeśli chodzi o wybór - obie formy są poprawne, byleby znak otwierający zgadzał się ze znakiem kończącym. Na pierwszy rzut oka używanie cudzysłowów albo apostrofów nie różni się od siebie działaniem. Różnica jednak jest, o czym wiele osób - szczególnie początkujących nie ma pojęcia. Różnica jest w sposobie interpretacji zawartości objętej cudzysłowem/apostrofem jak i co za tym idzie - w szybkości przetwarzania kodu przez interpreter. Pisząc kod zawsze powinniśmy starać się o to, aby był on jak najprostszy i jak najszybciej kompilowany przez interpreter. Te malutkie z pozoru różnice w czasie wykonywania kodu urastają do trochę większych, gdy serwer musi obsłużyć takich wykonań tysiące i ma ku temu ograniczone zasoby. Trzeba o tym pamiętać. Wróćmy zatem do tematu o jakim jest ten tekst.

Popatrzmy na przykład poniżej. Z pozoru obie linijki kodu nie różnią się niczym i wykonają się tak samo, ale jak to mówią - pozory mylą.
[code]
<?php
$zmienna1 = "jakiś tekst";
$zmienna2 = 'jakiś tekst';
?>[/code]
Dla człowieka niby tak samo, a jednak dla interpretera PHP zupełnie inaczej. Na czym więc polega różnica w obu zapisach (poza faktem wizualnym oczywiście)? Otóż polega ona na tym w jaki sposób PHP traktuje taki ciąg znaków. Aby bardziej zobrazować sobie to na przykładzie, popatrzmy na poniższe:
[code]
<?php
$kolor = 'czerwony';
$str1 = "Mój ulubiony kolor to: $kolor";
$str2 = 'Mój ulubiony kolor to: $kolor';
echo $str1 . '<br />';
echo $str2;

/*
Wynik:
Mój ulubiony kolor to: czerwony
Mój ulubiony kolor to: $kolor
*/
?>[/code]
Jak widać wyświetlenie zmiennej $str1 i $str2 daje zupełnie inne wyniki. Powodem jest fakt, iż ciągi objęte w cudzysłowy ( " ) są przez PHP interpretowane, natomiast ciągi objęte w apostrofy ( ' ) już nie. Ciąg objęty w cudzysłowy musi być zatem przez PHP przeparsowany i przetworzony w celu m.in. podstawienia wartości ewentualnie występujących w nim zmiennych, co za tym idzie - jest to jakieś dodatkowe zadanie dla procesora. Ciąg natomiast objęty w apostrofy jest z marszu traktowany jako zwykły, najzwyklejszy tekst i nie jest w żaden sposób przetwarzany, co za tym idzie - jest "obrabiany" przez PHP o wiele szybciej. Różnicę zauważymy też m.in. w przetwarzaniu znaków specjalnych, jak np. znak końca linii:
[code]
<?php
$str1 = "To jest pierwsza linia.\nTo jest druga linia.";
$str2 = 'To jest pierwsza linia.\nTo jest druga linia.';
?>[/code]
Wyświetlenie teraz zmiennej $str1 pokaże nam:
[code]
To jest pierwsza linia.
To jest druga linia.[/code]

Natomiast wyświetlenie drugiej zmiennej - $str2 pokaże:
[code]To jest pierwsza linia.\nTo jest druga linia.[/code]
W drugim przypadku znak "\n" nie zostanie w żaden sposób przetworzony na znak końca linii i potraktowany "na surowo".
Trzeba mieć też świadomość, że ciąg objęty w cudzysłowy jest przetwarzany przez PHP nawet wtedy, gdy nie ma w nim żadnych zmiennych, ani żadnych znaków specjalnych (trzeba przecież przeparsować wszystko, aby sprawdzić czy takowe nie występują). Jest to obciążenie dla interpretera i powinno się tego unikać. Pamiętajmy zatem więc, żeby zawsze wszędzie tam, gdzie nie ma konieczności używania cudzysłowów (a czasem taka potrzeba jest) używać zwykłych apostrofów.

[CSS3] Zaokrąglanie narożników

2015-05-31T02:19:00.001+02:00

CSS3 pozwala na tworzenie zaokrąglonych elementów. To co kiedyś trzeba było robić za pomocą specjalnie przyciętych obrazków, teraz można zrobić za pomocą stylu CSS. Wszystkie przeglądarki obsługują tą własność poprawnie, więc w tym przypadku nie trzeba posiłkować się prefixami przeglądarek, co zawsze wydłuża definicję styli. W tym krótkim wpisie nauczymy się robić zaokgrąglone obramowania dla elementów. Zaokrąglone krawędzie można zaaplikować praktycznie do każdego blokowego elementu HTML. Własność CSS jaka będzie nas interesować w celu zaokrąglenia narożnika elementu to:

[code]border-radius: wartość [px];[/code]

Możemy zaokrąglić wszystkie 4 narożniki, lub tylko któryś z nich, bądż też każdy z nich za pomocą innej wartości. Na początek określmy jedną wartość dla wszystkich rogów. Popatrzmy na prykłady z różnymi kombinacjami. Im więcej pikseli podamy w zaokrągleniu tym bardziej owalny będzie narożnik. Wszystkie poniższe zaokrąglenia generowane są za pomocą CSS.

border-radius: 25px	border-radius: 5px
div { border-radius: 25px; background: #8AC007; color: #fff; padding: 20px; width: 300px; height: 250px; }	div { border-radius: 5px; background: none; border: 5px solid #8AC007; color: #000; padding: 20px; width: 300px; height: 250px; }
border-radius: 50px	border-radius: 30px
div { border-radius: 50px; background-image:url('monica.jpg'); background-repeat: no-repeat; background-position: left top; border:1px solid #000; padding: 20px; width: 300px; height: 250px; }	div { border-radius: 30px; background-image:url('angelina.jpg'); background-repeat: no-repeat; background-position: left top; border: 5px dotted #8AC007; padding: 20px; width: 300px; height: 250px; }

A teraz zobaczmy jak określić każdy narożnik z osobna. Można to zrobić za pomocą podania wartości dla wszystkich 4 narożników we własności border-radius, lub wykorzystać własności przeznaczone dla każdego narożnika pojedyńczo, czyli:

border-top-left-radius - lewy górny róg
border-top-right-radius - prawy górny róg
border-bottom-right-radius - dolny prawy róg
border-bottom-left-radius - dolny lewy róg

W przypadku podawania 4 różnych wartości w border-radius, zaczynamy od lewego górnego rogu, następnie każda kolejna wartość odpowiada następnemu rogowi zgodnie z ruchem wskazówek zegara. Przykłady poniżej:

border-radius: 25px 0 0 0	border-radius: 0 25px 0 0
div { border-radius: 25px 0 0 0; background: #8AC007; color: #fff; padding: 20px; width: 300px; height: 250px; }	div { border-radius: 0 25px 0 0; background: #6b9503; color: #fff; padding: 20px; width: 300px; height: 250px; }
border-radius: 0 0 0 25px	border-radius: 0 0 25px 0
div { border-radius: 0 0 0 25px; background: #6b9503; color: #fff; padding: 20px; width: 300px; height: 250px; }	div { border-radius: 0 0 25px 0; background: #8AC007; color: #fff; padding: 20px; width: 300px; height: 250px; }

[SOAP] Podstawy protokołu SOAP i tworzenie prostej usługi sieciowej

2015-05-29T23:54:00.003+02:00

SOAP (Simple Object Access Protocol) to protokół wymiany informacji pomiędzy różnymi hostami i aplikacjami sieciowymi. Jest niezależny od platformy i języka, gdyż wszelka wymiana danych odbywa się za pomocą powszechnie używanego języka XML. SOAP jest standardem komunikacji pomiędzy potencjalnie nie związanymi ze sobą usługami sieciowymi. Serwer udostępniający usługę sieciową (Web Service) może np. działać pod kontrolą ASP.NET, natomiast aplikacja kliencka może być napisana w PHP, bądż w każdym innym dowolnym języku. Cała wymiana danych odbywa się bowiem poprzez niezależny od platformy język XML. Jak działa SOAP? Otóż wyobraźmy sobie serwer, który może udostępniać daną usługę, np. podającą aktualną datę na serwerze. Serwer zatem posiada u siebie jakąś funkcję, która takową datę pobiera i może ją udostępnić na zewnątrz. Mając informację o tym jaki jest adres serwera i jak konkretnie taka funkcja się nazywa, aplikacja kliencka może wysłać do serwera żądanie z prośbą o wykonanie tej funkcji na serwerze i zwrócenia wygenerowanych przez nią danych do klienta. Zarówno żądanie od klienta jak i odpowiedź od serwera wysyłane są za pomocą specjalnie spreparowanego XML-a, nie ma więc znaczenia jaka aplikacja prosi o wykonanie żądania i nie ma też znaczenia jaka aplikacja to żądanie wykona, byleby zwróciła wynik za pomocą języka XML. Serwer SOAP może posiadać oczywiście więcej takich zdefiowanych funkcji i poza podaniem godziny na serwerze może np. posiadać funkcje zwracające na żądanie inne typy danych.

WSDL

Funkcje takie jednak muszą się jakoś nazywać - np. getDate(), getTime(), getSomething() itd.
Klient, który nie wie w jaki sposób poprosić serwer o dane informacje takich informacji nie otrzyma, gdyż najzwyczajniej w świecie nie będzie wiedział jakie funkcje taki serwer oferuje, jakie są ich nazwy i jakie dane zwracają. Z pomocą przychodzi tutaj specjalny język stworzony właśnie do opisu oferowanych przez daną usługę sieciową, czyli serwer funkcji wraz z opisem rodzaju zwracanych i przyjmowanych przez nie danych. Język ten nazywa się WSDL (Web Services Description Language) i służy klientowi jako źródło informacji o tym co może zaoferować mu dana usługa sieciowa. Jest to tak naprawdę również XML, tyle że o ściśle określonej strukturze. W interesie serwera (usługi sieciowej) jest przygotowanie takiego dokumentu WSDL, bo po co komu udostępnianie jakiś funkcji, skoro nikt nie może z nich skorzystać, gdyż zwyczajnie o nich nie wie.

Komunikacja po HTTP

Informacje pomiędzy serwerem i klientem zazwyczaj przesyłane są po protokole HTTP. Ma to o tyle ciekawą zaletę, że protokół ten prawie nigdy nie jest zablokowany przez zapory sieciowe, co za tym idzie - mamy prawie, że pewność, że przesyłane dane nie utkną gdzieś po drodze na jakimś firewallu, który zablokowałby je, gdyby były wysłane po jakimś dziwnym, niestandardowym porcie.

Zastosowania

Większość szanujących się dużych usługodawców udostępnia swoje usługi za pomocą protokołu SOAP. Robi tak np. Google ze swoim API, robi tak także nasze rodzime (przynajmniej kiedyś) Allegro, które udostępnia swoje API poprzez SOAP, dzięki któremu możemy tworzyć aplikacje pobierające np. informacje o naszych aukcjach, czy kontrahentach. Zastosowanie SOAP-a jest więc powszechne na świecie i warto byłoby posiadać choćby podstawową wiedzę na temat korzystania z tego protokołu. Nic również nie stoi na przeszkodzie, aby utworzyć swoją własną usługę sieciową za pomocą protokołu SOAP co nawet tutaj uczynimy i zobaczymy, że nie jest to wcale takie trudne jak może się wydawać.

Schemat działania

Na samym początku klient prosi usługę sieciową o przedstawienie wszystkich funkcji jakie ona udostępnia do wykonania i jakie dane one zwracają. Serwer odbiera prośbę i odsyła klientowi dokument WSDL zawierający spis wszystkich takich funkcji wraz z ich nazwami, przyjmowanymi parametrami oraz rodzajem wartości jakie zwracają w wyniku.

W tym momencie klient wie już, że na serwerze dostępna jest funkcja o nazwie np. getTime(), która pobiera aktualny czas na serwerze i zwraca wynik w formacie podanym jako parametr. Zwracana wartość jest zwracana jako ciąg znaków o czym klient zostaje poinformowany za pomocą WSDL.

Funkcja na serwerze może mniej więcej wyglądać tak:
[code]
function getTime($time_format)
{
return date($time_format);
}
[/code]

Klient wiedząc już teraz, że istnieje taka funkcja, że ma nazwę 'getTime' i że zwraca ona dane jako string, oraz że przyjmuje parametr również w spostaci stringu określający format podania czasu, może poprosić serwer o wykonanie tej funkcji podając jej nazwę i parametr, a następnie odebrać od serwera wynik jej działania, oczekując w odpowiedzi ciągu tekstowego zawierającego godzinę na serwerze:

Jak wiec widzimy, cała procedura polega na wysłaniu do serwera prośby o wykonanie danej funkcji, wykonaniu tej funkcji przez serwer, pobrania i odesłaniu wyniku przez serwer, a następnie odebraniu tego wyniku przez klienta. Z tak odebranymi danymi klient następnie może już robić co chce.

Przykładowa usługa sieciowa

Możemy przetestować działanie jednego z dostępnych publicznie webservice'ów w praktyce, aby zobaczyć jak to wygląda.
Wejdżmy np. na stronę: http://www.ripedev.com/webservices/localtime.asmx
Usługa tutaj posiada jedną funkcję: LocalTimeByZipCode(), która po podaniu jako parametr kodu pocztowego zwraca czas lokalny w jego lokalizacji.

Jednocześnie możemy przyjrzeć się plikowi WSDL jaki posiada taka usługa:
Do definicji WSDL zawsze dostajemy się poprzez wywołanie:
[code]http://adres_serwera.com/?WSDL[/code]
W tym przypadku wejdżmy na:
http://www.ripedev.com/webservices/localtime.asmx?WSDL
Zobaczymy jak wygląda taka definicja WSDL "od środka". Jak widzimy jest do dokument XML, dość obszerny tak swoją drogą jak na tylko jedną funkcję, ale bez obaw - takich dokumentów nie tworzymy ręcznie, są one generowanie przez serwer SOAP. Tutaj mała uwaga - pisząc 'dokument WSDL' nie mam na myśli fizycznego pliku, gdyż dokument ten jest niejako generowany w locie, nie istnieje on tak naprawdę fizycznie na serwerze.

Tworzymy własny serwer SOAP do testów

Stworzymy teraz swój własny serwer z prostą usługą sieciową, a następnie się z nią połączymy.
Pozwoli to nam zobaczyć jak to wszystko działa od środka. W PHP istnieje kilka implementacji protokołu SOAP, my wybierzemy implementację o nazwie:
[code]nuSOAP[/code]
Jest to prosta w obsłudze biblioteka, która pozwoli nam na bezproblemową pracę z usługami sieciowymi. Instalacja jest prosta, sprowadza się do pobrania biblioteki i zapisania jej w folderze z naszym projektem.

Bibliotekę pobieramy stąd:
http://sourceforge.net/projects/nusoap/

Pobierzmy plik, rozpakujmy i zawartosć, czyli folder 'lib/' skopiujmy np. do:
[code]/ścieżka/do/naszego/katalogu/z/www/soap[/code]
tak abyśmy mieli dostęp do projektu, który zaraz stworzymy z adresu:
[code]http://localhost/soap[/code]

Utwórzmy teraz plik 'index.php' w naszym folderze '/soap' i zaincludujmy w nim pobraną bibliotekę:
[code]
<?php
/* index.php */
require_once("lib/nusoap.php");
?>
[/code]
Jesteśmy już gotowi do pracy z biblioteką nuSOAP.
Jako przykładową funkcję w naszej usłudze stworzymy sobie taką jaką omawialiśmy na przykładzie pobrania czasu z serwera. Nazwiemy ją tak samo - getTime(), a samą usługę sieciową nazwiemy 'mySOAP'.

Utworzenie usługi

Pracę rozpoczynamy od utworzenia obiektu klasy 'soap_server':
[code]$server = new soap_server();[/code]
Następnie wstępnie konfigurujemy naszą definicję WSDL, robimy to za pomocą:
[code]$server->configureWSDL(nazwa_naszej_usługi, $namespace)[/code]
gdzie:

nazwa_naszej_uslugi - nazwa pod jaką będzie widoczna nasza usługa
$namespace - przestrzeń nazw dla dokumentu XML, podamy tutaj na razie 127.0.0.1

Użyjemy zatem kodu:
[code]
$namespace = '127.0.0.1';
$server->configureWSDL('mySOAP', $namespace);
[/code]

Następnie określamy używaną przestrzeń nazw za pomocą:
[code]$server->wsdl->schemaTargetNamespace = $namespace;[/code]

Wstępna konfiguracja jest już za nami, mamy więc taki oto kod:
[code]
<?php
/* index.php */
require_once("lib/nusoap.php");
// załączamy bibliotekę nuSOAP

$server = new soap_server(); // tworzymy nowy obiekt serwera SOAP
$namespace = '127.0.0.1'; // definiujemy przestrzeń nazw dla XML

$server->configureWSDL('mySOAP', $namespace); // konfigurujemy nową usługę
$server->wsdl->schemaTargetNamespace = $namespace; // przypisujemy namespace do struktury tworzonego schematu WSDL
?>
[/code]

Stworzymy sobie teraz opisy metod/funkcji jakie udostępniać będzie nasza usługa.
Na początek stworzymy jedną metodę o nazwie:
[code]getTime()[/code]
przyjmującą jeden parametr określający format pobieranego czasu

Rejestracja metod/funkcji

Tutaj musimy się na chwile zatrzymać.
Każdą udostępnianą metodę/funkcję w nuSOAP musimy najpierw zarejestrować. Rejestracja taka polega na podaniu informacji o danej metodzie takich jak jej nazwa, przyjmowane i zwracane parametry, czy opis. Informacje te są wykorzystywane podczas generowania dokumentu WSDL, a także przez sam serwer podczas wywowyłania ich zdalnie. Metody rejestrujemy za pomocą:
[code]$server->register($method, $input, $output, $namespace, $soap_action, $style, $use, $documentation, $encoding_style);[/code]
gdzie:

$method - nazwa naszej metody, lub klasa.nazwa_metody
$input - tablica z argumentami jakie przyjmuje metoda, array('NAZWA_ARGUMENTU" => 'TYP_ARGUMENTU')
$output - tablica z wartościami jakie zwraca metoda, array('return" => 'TYP_ZWRACANEJ_WARTOŚCI')
$namespace - przestrzeń nazw dla XML
$soap_action - akcja dla metody lub false
$style - rpc|document, rodzaj generowania odpowiedzi
$use - encode|literal - tryb kodowania znaków
$documentation - opis naszej metody do pliku WSDL [opcjonalnie]
$encoding_style - zewnętrzny styl dla encodowania [opcjonalnie]

Zarejestrujmy teraz naszą metodę o nazwie 'getTime()'.
Jak pamiętamy przyjmuje ona jeden parametr typu string, zwraca wartość również typu string - będziemy musieli określić to w metodzie rejestrującej:
[code]
$server->register("getTime"
,array('time_format'=>'xsd:string')
,array('return'=>'xsd:string')
,$namespace
,false
,'rpc'
,'encoded'
,'To jest nasza testowa metoda zwracająca czas na serwerze'
);
[/code]

Metodę mamy już zarejestrowaną, pora na jej definicję.
Zrobimy to tak jak zwykle, definiując zwykłą funkcję, z małą różnicą na końcu:
[code]
function getTime($time_format)
{
$result = date($time_format);
return new soapval('return', 'xsd:string', $result);
}
[/code]
Ta mała różnica to zwracana wartość.
Jak widzimy w funkcji zarejestrowanej dla SOAP nie możemy zwrócić danych tak jak zazwyczaj, czyli poprzez:
[code]return $result;[/code]

Musimy tutaj za każdym razem wykorzystać obiekt klasy 'soapval', wg następującej składni:
[code]return new soapval(nazwa_zwracanej_wartości, rodzaj_zwracanej_wartości, $wartość);[/code]

Zauważmy, że jako nazwa zwracanej wartości podajemy tutaj 'return', co też określiliśmy podcza rejestracji metody w:
[code]array('return'=>'xsd:string')[/code]

Wyjaśnienia wymaga także zapis:
[code]xsd:string[/code]
W schemacie XSD w taki sposób właśnie podawać musimy typ zwracanej wartości.
Podstawowe typy danych to:

xsd:string
xsd:int
xsd:float
xsd:double
xsd:boolean

Pełną listę znajdziesz tutaj:
http://www.w3schools.com/schema/schema_dtypes_string.asp

Nasz kod w tym momencie wygląda więc tak:
[code]
<?php
/* index.php */
require_once("lib/nusoap.php");
// załączamy bibliotekę nuSOAP

$server = new soap_server(); // tworzymy nowy obiekt serwera SOAP
$namespace = '127.0.0.1'; // definiujemy przestrzeń nazw dla XML

$server->configureWSDL('mySOAP', $namespace); // konfigurujemy nową usługę
$server->wsdl->schemaTargetNamespace = $namespace; // przypisujemy namespace do struktury tworzonego schematu WSDL

// rejestrujemy metodę
$server->register("getTime"
,array('time_format'=>'xsd:string')
,array('return'=>'xsd:string')
,$namespace
,false
,'rpc'
,'encoded'
,'To jest nasza testowa metoda zwracająca czas na serwerze'
);

// definiujemy metodę
function getTime($time_format)
{
$result = date($time_format);
return new soapval('return', 'xsd:string', $result);
}
?>
[/code]

Teraz musimy jeszcze w jakiś sposób odbierać żądania.
Posłuży do tego poniższy kod:
[code]
$postdata = file_get_contents("php://input");
$postdata = isset($postdata) ? $postdata : '';
[/code]

Na sam koniec startujemy usługę, podając jako parametr ew. odebrane żądanie:
[code]$server->service($postdata);[/code]

Nasz kod finalnie wygląda tak:
[code]
<?php
/* index.php */
require_once("lib/nusoap.php");
// załączamy bibliotekę nuSOAP

$server = new soap_server(); // tworzymy nowy obiekt serwera SOAP
$namespace = '127.0.0.1'; // definiujemy przestrzeń nazw dla XML

$server->configureWSDL('mySOAP', $namespace); // konfigurujemy nową usługę
$server->wsdl->schemaTargetNamespace = $namespace; // przypisujemy namespace do struktury tworzonego schematu WSDL

// rejestrujemy metodę
$server->register("getTime"
,array('time_format'=>'xsd:string')
,array('return'=>'xsd:string')
,$namespace
,false
,'rpc'
,'encoded'
,'To jest nasza testowa metoda zwracająca czas na serwerze'
);

// definiujemy metodę
function getTime($time_format)
{
$result = date($time_format);
return new soapval('return', 'xsd:string', $result);
}

// odbieramy żądanie
$postdata = file_get_contents("php://input");
$postdata = isset($postdata) ? $postdata : '';

// startujemy usługę
$server->service($postdata);
?>
[/code]

Wejdżmy teraz w adres naszej usługi:
[code]http://localhost/soap[/code]
Jeśli wszystko wykonaliśmy poprawnie, powinien nam się ukazać opis naszej usługi:

Automatycznie generowany dokument WSDL zobaczymy wpisując adres:
[code]http://localhost/soap?wsdl[/code]
(nuSOAP wymaga podania WSDL małymi literami)

Voila!
Stworzyliśmy swoją własną, prostą usługę sieciową.

Aplikacja kliencka

Teraz czas na przetestowanie naszej usługi. Zobaczymy teraz jak połaczyć się z usługą po stronie klienta.
Stwórzmy plik 'client.php' o następującej treści:
[code]
<?php
/* client.php */
require_once('lib/nusoap.php');
// dołączamy bibliotekę

$wsdl = 'http://localhost/soap/?wsdl'; // URL do wsdl naszego serwera
$client = new nusoap_client($wsdl, 'wsdl'); // tworzymy obiekt klienta
$params = array('time_format' => 'H:i:s'); // definujemy parametry wywoływanej funkcji

$response = $client->call('getTime', $params);
// wywołujemy zdalną funkcję

echo('SERVER TIME: '. $response);
?>
[/code]
W pierwszej kolejności załaczamy oczywiście bibliotekę nuSOAP.
Następnie definiujemy URL do naszej usługi (z koncówką ?wsdl) i podajemy go do konstruktora obiektu klienta:
[code]$client = new nusoap_client(url_do_definicji_wsdl, wsdl);[/code]
gdzie w drugim parametrze podajemy 'wsdl', jeśli łączymy się z definicją WSDL.
W kolejnym kroku definiujemy tablicę z argumentami z jakimi wywołamy zdalną funkcję oraz wywołujemy samą funkcję za pomocą:
[code]$client->call(nazwa_zdalnej_funkcji, parametry);[/code]

Jeśli wszystko poszło po naszej myśli, to powinniśmy połączyć się z naszą usługą sieciową, uruchomić na niej zdalną funkcję i odebrać z serwera wynik jaki zwróciła:

Jak widać, nie jest to bardzo skomplikowane.
W kilku krokach stworzyliśmy swój własny serwer SOAP oraz nauczyliśmy się wywoływania zdalnych metod i odbierania od nich danych. Oczywiście są to absolutne podstawy i do bardziej skomplikowanej pracy nie wystarczą, ale jest to już pewna podbudowa, gdy umiemy korzystać z czegoś choćby w wersji podstawowej i wiemy "z czym to się je". W następnych artykułach opiszę bardziej zaawansowane metody pracy z SOAP wraz z przykładami, a póki co - wiedza zdobyta w tym artykule niech stanowi dla nas podstawę i zachętę do dalszej nauki protokołu SOAP.

Dla ciekawskich: dokumentacja webAPI oferowanego przez Allegro.pl, oczywiście za pomocą SOAP: http://allegro.pl/webapi/documentation.php

[SVN] Instalacja klienta i serwera oraz podstawy pracy z SVN

2015-05-29T18:35:00.000+02:00

SVN to najpopularniejszy i najczęściej używany na świecie system kontroli wersji. Z wersjonowania za pomocą SVN korzystają najwięksi gracze na rynku, tacy jak Google, Wordpress i wiele innych znanych marek. Taka rekomendacja już na starcie powinna wystarczyć do uznania Subversion za system wysoce niezawodny. Projekt wersjonowany za pomocą SVN dzieli się na dwie niezależne od siebie kwestie - na repozytorium główne, przechowywane na serwerze systemu kontroli wersji oraz na jego kopie robocze, dostępne zdalnie, na których lokalnie pracują związani z repozytorium programiści. O ile pobranie gotowego repozytorium i praca na nim nie wymaga zbyt wielu zabiegów, to już postawienie serwera SVN może być nieco kłopotliwe dla osób, które robią to po raz pierwszy. Dlatego też w artykule tym omówię krok po kroku w jaki sposób uruchomić na swoim komputerze zarówno klienta jak i serwer systemu kontroli wersji Subversion. Artykuł dotyczyć będzie instalacji na systemach z rodziny Windows, linuxowcom nie trzeba tłumaczyć jak SVN-a zainstalować ;)

Wstęp

Na początek zobaczmy jak wygląda dostęp do gotowego repozytorium. Do repozytorium dostaniemy się z poziomu zwykłego WWW, wejdźmy sobie na repozytorium Wordpressa:
http://svn.automattic.com/wordpress/trunk/

Jak widzimy, mamy od razu wylistowaną listę plików zawartych w repozytorium oraz informację, której rewizji dotyczą obecne wersje plików. W chwili pisania tego tekstu (na dzień 29.05.2015) jest to rewizja o numerze 32622. Przy każdej kolejnej zmianie w kodzie (tzw. commicie) numer rewizji jest zwiększany o jeden.

Klient

Po stronie klienta pracować będziemy na kopii roboczej repozytorium, nie na jego właściwej wersji. Pracować z SVN możemy w konsoli, jak i za pomocą windowsowego graficznego GUI o nazwie TortoiseSVN. W opisie tym nauczymy się jednego i drugiego. Na samym początku pobrać musimy najnowszą wersję klienta SVN ze strony:
http://sourceforge.net/projects/win32svn/
Zróbmy więc to i zainstalujmy SVN w swoim systemie.

Kolejnym krokiem będzie pobranie graficznego klienta o nazwie TortoiseSVN, którego pobierzemy sobie stąd:
http://tortoisesvn.net/downloads.html

Po instalacji, sprawdżmy, czy wszystko działa poprawnie.
SVN powinien nam dodać ścieżkę do zmiennej PATH w systemie, np:
[code]C:\Program Files (x86)\Subversion\bin[/code]
Jeśli tak się nie stało - musimy ją dodać ręcznie:
[code]Komputer >> Zaawansowane >> Zmienne środowiskowe >> PATH[/code]
Wejdżmy teraz do konsoli i wpiszmy:
[code]$ svn --version[/code]

Jak widzimy wyświetliła nam się obecna zainstalowana wersja.

Sprawdźmy teraz klienta Tortoise - powinien on dodać kilka elementów do powłoki systemu.
Utwórzmy jakiś folder, np. C:/svntest i kliknijmy na nim prawym przyciskiem myszy, powinniśmy zobaczyć menu kontekstowe klienta Tortoise:

Pobierzmy sobie dla testów przedstawione wcześniej repozytorium Wordpressa:
Mając utworzony folder:
[code]C:/svntest[/code]
i będąc w konsoli, wejdźmy do niego i wpiszmy to co poniżej:
[code]
$ cd C:/svntest
$ svn checkout http://svn.automattic.com/wordpress/trunk wordpress
[/code]

Pobierze nam to kopię lokalną repozytorium Wordpressa do katalogu:
[code]C:/svntest/wordpress/[/code]

Zauważmy, iż w każdym repozytorium znajdzie się nam ukryty folder o nazwie ".svn" - pod żadnym pozorem nie modyfikujmy ręcznie plików w nim zawartych.

Teraz to samo zróbmy za pomocą klienta graficznego.
Wiemy już, że do pobrania repozytorium służy komenda "checkout".
Utwórzmy teraz folder:
[code]C:/svntest/wordpress2[/code]
i klijnijmy na nim prawym przyciskiem myszy wybierając opcję "SVN Checkout...":

Pojawi się okno, w którym wpiszmy adres repozytorium:
[code]http://svn.automattic.com/wordpress/trunk[/code]

Jak widać - pobrania kopii repozytorium możemy dokonać zarówno z poziomu poleceń w konsoli jak i z poziomu łatwego w użyciu klienta graficznego. To wszystko - od tej chwili możemy dowolnie pracować na pobranej kopii roboczej repozytorium.

Testowy plik

Dodajmy teraz jakiś plik do pobranej kopii repozytorium, niech to będzie np.:
[code]test.txt[/code]
Plik taki dodaliśmy jednak jedynie do naszego folderu, nie jest on jeszcze jednak uwzględniony w repozytorium, co za tym idzie nie jest śledzony przez SVN. Aby dołączyć nowy plik do repozytorium używamy polecenia "add":

[code]$ svn add test.txt[/code]

Aby dodać wszystkie nowe pliki używamy gwiazdki:
[code]$ svn add *[/code]

Analogicznie dla podfolderu:
[code]$ svn add podfolder/*[/code]

Od tej chwili plik ten jest już zawarty w lokalnej, roboczej kopii repozytorium i śledzony przez SVN.
To samo możemy zrobić z poziomu klienta Tortoise:

Jesteśmy obecnie wciąż w rewizji jaką pobraliśmy z serwera Wordpressa. Aby dodać nasz nowy plik do właściwego repozytorium, a więc zatwierdzić zmiany jakich dokonaliśmy - musimy te zmiany "zacommitować". Tym samym numer rewizji zwiększy się o jeden.

Służy do tego polecenie:
[code]$ svn commit -m "Komentarz do rewizji"[/code]

lub to samo w kliencie graficznym:

Niestety żadnych zmian w tym momencie nie zatwierdzimy, gdyż nie mamy odpowiednich uprawnień do repozytorium Wordpressa. Różnica pomiędzy SVN i GIT-em jest taka, że w Gicie wszelkie zmiany commitujemy do kopii roboczej znajdujacej się lokalnie na naszym komputerze i dopiero potem wysyłamy na serwer, w SVN natomiast commitujemy je bezpośrednio do repozytorium źródłowego. Aby więc przetestować to wszystko w praktyce, potrzebujemy serwera, do którego będziemy mieć pełny dostęp, co też uczynimy poniżej.

Serwer

Postawmy teraz własny serwer, aby w pełni przetestować pracę z SVN, taką jak zatwierdzanie zmian, czy łączenie kopii roboczej z głównym repozytorium (z Wordpressem tego nie zrobimy, nie posiadamy uprawnień - możemy jedynie pobrać kopię roboczą repozytorium). O ile sprawa z klientem była prosta, o tyle postawienie własnego serwera SVN nie będzie już takie proste.
Co należy wiedzieć, to to, że serwer SVN postawić możemy na dwa sposoby - za pomocą oddzielnej aplikacji (dostępnej tylko na systemy unixowe), lub za pomocą odpowiedniego modułu do serwera Apache. Wykorzystamy tą drugą opcję, zatem koniecznym jest, abyśmy posiadali działającego lokalnie Apacha - bez tego nie zrobimy nic. Instalacji Apacha nie będę tutaj opisywał i zakładam, że takowy serwer już u nas działa.

1. Pobranie modułów SVN

Co musimy teraz zrobić? Musimy pobrać odpowiednie do naszej wersji serwera dodatkowe moduły.
Będą to dwa pliki:

mod_authz_svn.so
mod_dav_svn.so

Pliki te są dostępne w folderze z zainstalowanym Subversion/bin.
Niestety skopiowanie ich stąd w niektorych przypadkach spowodować może, że nasz serwer nie będzie w stanie wystartować. Powód? Istnieje kilka wersji Apacha, z czego najgłówniejszym podziałem jest podział na wersje 2.2x i 2.4x. Dodatkowo możemy posiadać wersję 32, albo 64 bitową. W przypadku niezgodności wersji możemy mieć problem z uruchomieniem serwera z powyższymi modułami, pobrać musimy zatem wersję odpowiednią dla NASZEJ wersji serwera.
Odpowiednią wersję znajdziemy na stronie:
https://www.apachehaus.com/cgi-bin/download.plx
w odpowiednich sekcjach:
[code]Modules for Apache 2.2.x i Modules for Apache 2.4.x[/code]
Paczka ma nazwę:
[code]Mod Subversion x.x.x. for Apache 2.x.x[/code]

Ja osobiście posiadam 64-bitową wersję Apache'a z numerkiem 2.4.9, pobieram więc odpowiednią dla mnie wersję:
mod_svn-1.8.11-ap24-vc9-x64.zip.

2. Instalacja modułów SVN

Po pobraniu odpowiedniego archiwum, rozpakowujemy je:

Pliki z folderu "modules/":

mod_authz_svn.so
mod_dav_svn.so

kopiujemy do:
[code]/ścieżka/do/apache/modules/[/code]

natomiast pliki z folderu "bin/" do:
[code]/ścieżka/do/apache/bin/[/code]

No dobrze, pliki już mamy, teraz czeka nas edycja pliku konfiguracyjnego Apache'a, ale najpierw przygotujmy sobie katalog, w którym nasz serwer będzie trzymał repozytoria, dla testów utwórzmy folder:
[code]C:/svnserver[/code]

3. Konfiguracja Apache'a

Wróćmy teraz do katalogu z Apachem i otwórzmy (w trybie administracyjnym) do edycji plik:
[code]/ścieżka/do/apache/conf/httpd.conf[/code]

Mając już otwarty plik z konfiguracją po pierwsze musimy włączyć dodane dopiero co moduły.
Szukamy sekcji z modułami, która wygląda mniej więcej tak:
[code]
# Example:
# LoadModule foo_module modules/mod_foo.so
#

LoadModule access_compat_module modules/mod_access_compat.so
LoadModule actions_module modules/mod_actions.so
LoadModule alias_module modules/mod_alias.so
LoadModule allowmethods_module modules/mod_allowmethods.so
LoadModule asis_module modules/mod_asis.so
LoadModule auth_basic_module modules/mod_auth_basic.so
#LoadModule auth_digest_module modules/mod_auth_digest.so
#LoadModule authn_anon_module modules/mod_authn_anon.so
LoadModule authn_core_module modules/mod_authn_core.so
#LoadModule authn_dbd_module modules/mod_authn_dbd.so
#LoadModule authn_dbm_module modules/mod_authn_dbm.so
[...]
[/code]
i szukamy modułu 'mod_dav.so':
[code]#LoadModule dav_module modules/mod_dav.so[/code]

Będzie on najprawdopodobniej zakomentowany znakiem #, usuwamy ten znak.
Następnie dodajemy wpisy z naszymi skopiowanymi dopiero co modułami:
[code]
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
[/code]

Zapisujemy plik 'httpd.conf' i restarujemy Apache'a.
Jeśli moduły załadowały się poprawnie i serwer wystartował, to wracamy do dalszej konfiguracji.
Pod koniec pliku 'httpd.conf' dodajmy następujące:
[code]
<Location /svnserver>
DAV svn
SVNPath "C:/svnserver/myTestRepo"
</Location>
[/code]
Określa to ścieżkę do naszego repozytorium (które za chwilę utworzymy).
Ponownie zapisujemy plik i restartujemy serwer.

4. Tworzymy repozytorium

Teraz czas na utworzenie testowego repozytorium:
W terminalu zrobimy to tak:
[code]
$ cd C:/svnserver
$ svnadmin create myTestRepo
[/code]

Za pomocą klienta Tortoise zrobimy to następująco:
Wchodzimy w folder C:/svnserver, tworzymy w nim folder 'myTestRepo', klikamy na nim prawym przyciskiem myszy i wybieramy opcję:
[code]TortoiseSVN -> Create repository here[/code]

Zostanie utworzone repozytorium, wybieramy opcję 'Create folder structure' i [OK]:

Nasze repozytorium zostało utworzone.

Wchodzimy teraz z poziomu przeglądarki na adres:
[code]http://localhost/svnserver[/code]
Jeśli wszystko poszło zgodnie z planem, naszym oczom powinno się ukazać nasze świeżo ~~upieczone~~ utworzone repozytorium:

5. Pobieramy własne repozytorium

Mamy już działający serwer SVN, pobierzmy teraz kopię roboczą z własnego serwera.
Utwórzmy katalog 'C:/svnclient' i pobierzmy do niego kopię repozytorium z naszego serwera:
[code]
$ cd C:/
$ mkdir svnclient
$ cd svnclient
$ svn checkout http://localhost/svnserver testRepo
$ cd testRepo
[/code]

To samo możemy zrobić za pomocą klienta TortoiseSVN.
Nasza kopia została pobrana do:
[code]C:/svnclient/testRepo[/code]

Mamy już kopię roboczą, na której możemy pracować, utwórzmy w niej jakiś plik, ponownie np.:
[code]test.txt[/code]
Dodajmy następnie ten plik do repozytorium:
[code]$ svn add test.txt[/code]

I wejdźmy na nasz serwer:
[code]http://localhost/svnserver[/code]

Jak widać nasz plik test.txt nie pojawił się w naszym źródłowym repozytorium, istnieje jedynie w naszej kopii roboczej.
Aby wysłać zmiany na serwer, do głównego repozytorium, musimy wykonać operację "commit", która zatwierdzi zmiany w kopii roboczej i stworzy nową rewizję na serwerze:

Zrobimy to w konsoli:
[code]$ svn commit -m "Dodano nowy plik"[/code]

lub za pomocą Tortoise:

Wejdźmy ponownie na nasz serwer:
[code]http://localhost/svnserver[/code]

jak widzimy plik pojawił się w naszym głównym repozytorium, a rewizja zwiększyła się o jeden.

Dokonajmy teraz jakiś zmian w pliku 'test.txt', pododawajmy nowe pliki i poróbmy kilka kolejnych 'commitów'.
Jak widać, za każdym razem numer rewizji zwiększa się.

Aby teraz przejrzeć historię naszych rewizji użyjemy ładnego graficznego GUI wchodzącego w skład pakietu Tortoise.
Klikając PPM na danym pliku i wybierając z menu:
[code]TortoiseSVN -> RevisionGraph[/code]
dostajemy do dyspozycji narzędzie pokazujące nam historię naszego pliku, narazie jest ona uboga, ale zobaczmy:

Oczywiście w SVN w każdej chwili możemy przywrócić stan pliku z przed danej rewizji.
W tym przecież tkwi potęga systemów wersjonowania kodu :)

Innymi przydatnymi programami z pakietu Tortoise będą też:

[code]TortoiseSVN -> ShowLog[/code]

oraz

[code]TortoiseSVN -> Repository Browser[/code]

6. Update

Co jeśli repozytorium na serwerze zmieni się, a my posiadamy np. starszą jego kopię?
Do synchronizacji służy polecenie:
[code]$ svn update[/code]
Zobaczmy na przykładzie:

Do tego samego służy analogiczna opcja dostępna w menu kontekstowym Tortoise:

7. Autoryzacja

Pozostaje nam jeszcze kwestia zabezpieczenia naszego serwera hasłem, tak aby jedynie wybrani użytkownicy mieli dostęp do repozytorium. Zrobimy to za pomocą modułu uwierzytelniania Apache'a. Na temat uwierzytelniania krok po kroku pisałem w tym artykule.

Na początek utworzymy plik z hasłami dla uprawnionych użytkowników, zrobimy to za pomocą apachowego polecenia:
[code]htpasswd[/code]
które służy do generowania plików z hasłami.

Utwórzmy np. hasła dla użytkowników:

janusz
anna

W terminalu wpiszmy:
[code]
$ /ścieżka/do/apache/bin/htpasswd -cm C:/svn-auth janusz
[podajemy hasło]

$ /ścieżka/do/apache/bin/htpasswd -m C:/svn-auth anna
[podajemy hasło]
[/code]

Utworzy nam to plik z hasłami:
[code]C:/svn-auth[/code]

dla użytkowników:

janusz
anna

Plik ten skopiujmy do:
[code]/ścieżka/do/apache/conf/svn-auth[/code]

Następnie w pliku konfiguracyjnym apacha:
[code]/ścieżka/do/apache/conf/httpd.conf[/code]

zmieńmy dodaną wcześniej linijkę:
[code]
<Location /svnserver>
DAV svn
SVNPath "C:/svnserver/myTestRepo"
</Location>
[/code]
na:
[code]
<Location /svnserver>
DAV svn
SVNPath "C:/svnserver/myTestRepo"
AuthType Basic
AuthName "Login to SVN"
AuthUserFile "conf/svn-auth"
Require valid-user
</Location>
[/code]
Zapiszmy plik i zrestartujmy serwer.
Od tej chwili dostęp do repozytorium dostępny jest jedynie za podaniem loginu i hasła.

Importowanie starego projektu do SVN

Co w przypadku jeśli mamy jakiś swój projekt i chcemy od tej chwili pracować z nim za pomocą SVN? Służy do tego polecenie 'import', które tworzy repozytorium dla istniejącego już projektu.

Dla testów stwórzmy sobie folder:
[code]C:/oldProject[/code]
a w nim jakieś przykładowe pliki, np.:

test.txt
test2.txt

Kolejnym krokiem jest utworzenie nowego pustego repozytorium na serwerze, np. tutaj:
[code]C:/svnserver/myImportedRepo[/code]

Zainicjujmy puste repozytorium o nazwie 'myImportedRepo' w folderze 'C:/svnserver':
[code]
$ cd C:/svnserver
$ svnadmin create myImportedRepo
[/code]

Następnie dodajmy nową ścieżkę do repozytorium w konfiguracji Apache'a w pliku 'httpd.conf':
[code]
<Location /svnserver2>
DAV svn
SVNPath "C:/svnserver/myImportedRepo"
</Location>
[/code]
Zapiszmy plik i zrestartujmy Apache'a.
Repozytorium 'myImportedRepo' będzie dostępne pod adresem:
[code]http://localhost/svnserver2[/code]

Następnie, aby zaimportować pliki z folderu:
[code]C:/oldProject[/code]
do repozytorium:
[code]C:/svnserver/myImportedRepo[/code]

wpisujemy w konsoli:
[code]
$ cd C:/
$ svn import -m "Importujemy pliki" oldProject http://localhost/svnserver2
[/code]

Możemy to też zrobić za pomocą Tortoise:

I to wszystko. Nasze repozytorium zawierające śledzone od tej pory przez Subversion pliki dostępne jest teraz pod adresem:
[code]http://localhost/svnserver2[/code]

I to tyle na początek, w kolejnych artykułach opiszę dalsze aspekty pracy z Subversion.
Na chwilę obecną wiemy już jak używać klienta i jak postawić serwer, a także znamy już podstawy pracy z SVN, co na początek powinno umożliwić nam zapoznanie się z Subversion i podstawową możliwość pracy z repozytoriami.

[PHP][GD2] Używanie czcionek TrueType

2015-05-28T20:00:00.000+02:00

Standardowa czcionka używana do tworzenia tekstu za pomocą imagestring() łagodnie rzecz ujmując pozostawia wiele do życzenia, warto zatem wiedzieć, że za pomocą biblioteki GD można "pisać" po obrazie dowolną czcionką. Czcionek w internecie znajdziemy multum, wybór ograniczony jest tutaj jedynie wyobraźnią. Co najlepsze - dołączenie zewnętrznej czcionki nie wymaga w GD jakiś specjalnych zabiegów - wszystko sprowadza się do pobrania pliku .ttf z zadaną czcionką TrueType, umieszczeniu go na serwerze, a następnie dołączeniu go do skryptu. W tym bardzo krótkim wpisie pokażę jak za pomocą kilku linijek kodu wygenerować efekt taki jak na obrazku poniżej:

Czcionka na powyższym obrazku została dołączona za pomocą PHP, nie została dodana w żadnym programie graficznym. Nazywa się Nasty i możecie ją pobrać stąd. Zdjęcie na jakim wygenerowano napis stąd. Opiszę teraz w skrócie jak za pomocą zewnętrznej czcionki wygenerować na obrazie napis jak wyżej. Na początek pobierzmy sobie tą czcionkę (plik .ttf) w celach testowych i zapiszmy w katalogu, gdzie pisać będziemy nasz kod. Do pisania czcionką TrueType, którą załączamy z zewnetrznego pliku .ttf służy funkcja:

[code]imagettftext($image, $font_size, $angle, $x, $y, $color, $font, $text);[/code]
gdzie:

$image - uchwyt do obrazu
$font_size - rozmiar czcionki w px
$angle - kąt obrotu czcionki w stopniach
$x - współrzędna X, od której zaczynamy pisanie
$y - współrzędna Y, od której zaczynamy pisanie
$color - kolor czcionki
$font - nazwa pliku z czcionką
$text - pisany tekst

Zobaczmy na przykładzie:
[code]
<?php
$image = imagecreatefromjpeg("angelina.jpg");
$white = imagecolorallocate($image, 255, 255, 255);
$black = imagecolorallocate($image, 0, 0, 0);

$font = 'nasty.ttf';
$txt = 'ANGELINA';
$x = 400;
$y = 350;
$size = 90;
$angle = 0;

imagettftext($image, $size, $angle, $x+1, $y+1, $black, $font, $txt); // +1px w dół, +1px w prawo
imagettftext($image, $size, $angle, $x-1, $y-1, $black, $font, $txt); // -1px w górę, -1px w lewo
imagettftext($image, $size, $angle, $x, $y, $white, $font, $txt);

header('Content-type: image/png');
ImagePNG($image);
imagedestroy($image);
?>[/code]
Powyższy kod wygeneruje dokładnie taki sam efekt jak na załączonym obrazku.
Ot cała filozofia. Warto jednak zwrócić uwagę na fakt, iż tekst jest tutaj tworzony aż trzy razy. Dlaczego? Otóż właściwym tekstem jest ten o kolorze białym, tekst pisany czcionką czarną robi tutaj za obramowanie i jest przesunięty pod spodem o jeden pixel najpierw w górę, potem w dół, a także o jeden pixel na boki. Powodem zastosowania takiej konstrukcji jest to, że w bibliotece GD do pisania daną czcionką można użyć jednocześnie tylko jednego koloru, tym samym czcionka nie posiada tutaj żadnego widocznego konturu, co na niekontrastowym tle może powodować problem z widocznością. Rozwiązanie takie jak powyżej pozwala wyeliminować tą niedogodność i umożliwia nam uzyskanie czegoś w stylu efektu cienia, bądż konturu dla wyświetlanego tekstu.

[PHP][GD2] Prosty gradient i operacje na kolorach pikseli

2015-05-28T18:30:00.002+02:00

W bibliotece GD mamy pełną kontrolę nad każdym pikselem składającym się na wynikowy obrazek. Możemy dowolnie pobierać jego wartości i ustawiać nowe. Możliwość taka, w połączeniu z odpowiednio skonstruowanymi pętlami pozwala na bardzo wiele, m.in. na generowanie gradientów, czyli przejść pomiędzy kolorami. Funkcje do tworzenia złożonych gradientów są dość obszerne, my tutaj postaramy się nauczyć podstaw tworzenia prostych gradientów polegających na liniowym przejściu pomiędzy kolorami. Nauczymy się też operować na pikselach - pobierać oraz modyfikować ich wartości.

Tworzymy gradient

Popatrzmy na poniższy obrazek:

To prosty gradient wygenerowany bezpośrednio w PHP za pomocą jednej prostej pętli for. Aby móc tworzyć podobne obrazki za pomocą swoich funkcji trzeba zrozumieć zasadę działania takiego mechanizmu. Najprostrzym sposobem na wygenerowanie liniowego przejścia jest pętla przechodząca pionowo lub poziomo inkrementująca się o jeden piksel wraz z każdym kolejnym przebiegiem. W każdym przebiegu jednocześnie zmniejszana lub zwiększana musi być wartość zadanego przez nas koloru. Jak wiemy - kolory definiujemy za pomocą podawania ich odpowiednich wartości liczbowych w palecie RGB. Skoro więc są to zwykłe dane liczbowe, nic nie stoi na przeszkodzie, aby wykonywać na nich dowolne operacje matematyczne. Aby zrozumieć zasadę działania, stwórzmy sobie obrazek o szerokości 600px i wysokości 256 pikseli:
[code]
$width = 600;
$height = 256;
$image = imagecreatetruecolor($width, $height);
[/code]
następnie stwórzmy pętlę for, która będzie przebiegać pionowo po naszym obrazku:
[code]
for($i=0; $i < $height; $i++)
{
// ....
};
[/code]
Jak widzimy pętla przebiegać będzie po koleji po "wierszach" obrazka, począwszy od wiersza 0, na ostatnim wierszu (w tym przypadku 255) kończąc. Dodajmy teraz do naszej pętli następujący kod:
[code]
for($i=0; $i < $height; $i++)
{
$color = imagecolorallocate($image, $i, $i, $i);
imageline($image, 0, $i, $width, $i, $color);
};
[/code]
W każdym kolejnym przebiegu definiujemy nowy kolor, którego wartość będzie rosła liniowo wraz z inkrementacją zmiennej $i. Następnie rysujemy linię po całej szerokości naszego obrazka, o współrzędnej Y pobieranej również ze zmiennej $i. W każdym wierszu naszego obrazka będzie więc rysowana pozioma linia o wartości koloru rosnącej wraz z każdym przebiegiem pętli, aż do uzyskania końcowego miejsca na obrazie (255px w pionie).

Przetestujmy w praktyce:
[code]
<?php
$width = 600;
$height = 256;
$image = imagecreatetruecolor($width, $height);
for($i=0; $i < $height; $i++)
{
$color = imagecolorallocate($image, $i, $i, $i);
imageline($image, 0, $i, $width, $i, $color);
};
header('Content-Type: image/png');
imagepng($image);
imagedestroy($image);
?>
[/code]
Wynikiem będzie najprostszy z możliwych gradient:

Zmodfikujmy teraż nasz kod, tak aby pozwalał na wygenerowanie gradientu dla dowolnego rozmiaru obrazka - póki co mamy tu ograniczenie do 255px, bo tylko tyle maksymalnie może przyjąć wartość RGB. Musimy więc teraz w jakiś sposób obliczyć co ile pikeli mamy zwiększać wartość naszego koloru w zależności od całkowitej wysokości naszego obrazu.
Wykonany to poniższym sposobem:
[code]
for($i=0; $i<$height; $i++)
{
$color = floor($i * 255 / $height);
$color = imagecolorallocate($image, $color, $color, $color);
imageline($img, 0, $i, $width, $i, $color);
};
[/code]
Wartość koloru obliczamy algorytmem:
[code]współrzędnaY * 255 / całkowita_wysokość obrazka[/code]
Funkcja floor() zakokrągla nam wynik do najbliższej, najniższej wartości całkowitej, np. floor(3.14) da nam 3.

Zobaczmy teraz, czy to zadziała, np. dla obrazka o wymiarach 600x450px:
[code]
<?php
$width = 600;
$height = 450;
$image = imagecreatetruecolor($width, $height);
$white = imagecolorallocate($image, 255, 255, 255);

for($i=0; $i<$height; $i++)
{
$color = floor($i * 255 / $height);
$color = imagecolorallocate($image, $color, $color, $color);
imageline($image, 0, $i, $width, $i, $color);
};

imagestring($image, 5, 140, 210, 'RGB($color++, $color++, $color++)', $white);
header('Content-Type: image/png');
imagepng($image);
?>
[/code]

Jak widać działa. Gradient rozciągnął się na całą wysokość obrazu.
Nasze linearne wypełnienie jest jednak trochę nudne prawda? Dodajmy mu trochę koloru.
Jak to zrobić? Otóż w chwii obecnej zwiększamy w naszej pętli wartości wszystkich składowych RGB jednocześnie, co za tym idzie nasz gradient generuje się liniowo od koloru czarnego (RGB = 0,0,0) do koloru białego (RGB = 255, 255, 255). Zostawmy więc np. wartości koloru zielonego i niebieskiego w spokoju, a zwiększajmy jedynie wartość składowej czerwonej:
[code]
<?php
$width = 600;
$height = 450;
$image = imagecreatetruecolor($width, $height);
$white = imagecolorallocate($image, 255, 255, 255);

for($i=0; $i<$height; $i++)
{
$color = floor($i * 255 / $height);
$color = imagecolorallocate($image, $color, 0, 0);
imageline($image, 0, $i, $width, $i, $color);
};

imagestring($image, 5, 200, 210, 'RGB($color++, 0, 0)', $white);
header('Content-Type: image/png');
imagepng($image);
?>
[/code]
Wynik:

A teraz dla składowej zielonej:
[code]
<?php
$width = 600;
$height = 450;
$image = imagecreatetruecolor($width, $height);
$white = imagecolorallocate($image, 255, 255, 255);

for($i=0; $i<$height; $i++)
{
$color = floor($i * 255 / $height);
$color = imagecolorallocate($image, 0, $color, 0);
imageline($image, 0, $i, $width, $i, $color);
};

imagestring($image, 5, 200, 210, 'RGB(0, $color++, 0)', $white);
header('Content-Type: image/png');
imagepng($image);
imagedestroy($image);
?>
[/code]

I niebieskiej:
[code]
<?php
$width = 600;
$height = 450;
$image = imagecreatetruecolor($width, $height);
$white = imagecolorallocate($image, 255, 255, 255);

for($i=0; $i<$height; $i++)
{
$color = floor($i * 255 / $height);
$color = imagecolorallocate($image, 0, 0, $color);
imageline($image, 0, $i, $width, $i, $color);
};

imagestring($image, 5, 200, 210, 'RGB(0, 0, $color++)', $white);
header('Content-Type: image/png');
imagepng($image);
imagedestroy($image);
?>
[/code]

Jak widać, mamy tutaj duże pole do popisu odnośnie miksowania kolorów.
Warto też zauważyć, że tym sposobem możemy zabawić się również z przezroczystością modyfikujac liniowo wartość kanału alpha.

ImageColorAt() - pobieranie wartości koloru z piksela

Dzięki funkcji imagecolorat() możemy pobrać wartość koloru dla dowolnego piksela w obrazie. Zwracana wartość to indeks koloru w postaci liczby integer, musimy użyć przesunięć bitowych, aby uzyskać wartości poszczególnych składowych. Użycie funkcji przedstawia się następująco:
[code]$rgb = imagecolorat($image, $x, $y)[/code]
gdzie

$image - uchwyt do obrazka
$x - współrzędna X piksela
$y - współrzędna Y piksela

Wartość RGB pobierzemy tak:
[code]
$image = imagecreatefromjpeg('angelina.jpg');
$rgb = imagecolorat($image, 10, 15);
$pixel['r'] = ($rgb >> 16) & 0xFF;
$pixel['g'] = ($rgb >> 8) & 0xFF;
$pixel['b'] = $rgb & 0xFF;
[/code]
Możemy stworzyć sobie do tego prostą funkcję:
[code]
function getRgb($image, $x, $y)
{
$rgb = imagecolorat($image, $x, $y);
$pixel['r'] = ($rgb >> 16) & 0xFF;
$pixel['g'] = ($rgb >> 8) & 0xFF;
$pixel['b'] = $rgb & 0xFF;
return $pixel;
}
[/code]
Sprawdźmy w praktyce jak to działa.
Wczytajmy zdjęcie z Angeliną, nad którym pastwiliśmy się w tym artykule i pobierzmy wartości kilku pixeli, po czym wyświetlmy te wartości na obrazku:
[code]
<?php
function getRgb($image, $x, $y, $show = true)
{
$white = imagecolorallocate($image, 255, 255, 255);

$rgb = imagecolorat($image, $x, $y);
$pixel['r'] = ($rgb >> 16) & 0xFF;
$pixel['g'] = ($rgb >> 8) & 0xFF;
$pixel['b'] = $rgb & 0xFF;
// pobieramy wartości RGB do tablicy

if($show)
{
imageellipse($image, $x, $y, 10, 10, $white);
// rysujemy elipsę w miejscu badanego pixela

$str = 'R:'.$pixel['r'].' G:'.$pixel['g'].' B:'.$pixel['b'];
imagestring($image, 5, $x + 5, $y + 5, $str, $white);
// wyświetlamy wartość w miejscu badanego pixela
}
return $pixel; // zwracamy tablicę z wartościami RGB
}

$image = imagecreatefromjpeg("angelina.jpg");
$pixel_color[1] = getRgb($image, 100, 100);
$pixel_color[2] = getRgb($image, 400, 340);
$pixel_color[3] = getRgb($image, 130, 30);
// pobieramy RGB pixeli

header('Content-type: image/png');
ImagePNG($image);
imagedestroy($image);
?>
[/code]
Wynik:

ImageSetPixel() - ustawianie wartości RGB piksela

Analogicznie do funkcji pobierającej dane o wartości piksela mozemy zadziałać w drugą stronę - ustawić wartości pikseli. Służy do tego omawiana funkcja, której użycie wygląda tak:
[code]imagesetpixel($image, $x, $y, $color)[/code]
gdzie:

$image - uchwyt do obrazka
$x - współrzędna X piksela
$y - współrzędna Y piksela
$color - kolor jaki ustawiamy

Przykładowo, zmieńmy wartości kilku pikseli w lewym górnym rogu obrazka.
Jest tam akurat czarne tło - zmienimy kilka pixeli na kolor biały.
[code]
<?php
$image = imagecreatefromjpeg("angelina.jpg");
$white = imagecolorallocate($image, 255, 255, 255);

imagesetpixel($image, 20, 10, $white);
imagesetpixel($image, 30, 20, $white);
imagesetpixel($image, 4, 50, $white);
imagesetpixel($image, 50, 70, $white);
imagesetpixel($image, 10, 17, $white);
imagesetpixel($image, 44, 2, $white);
imagesetpixel($image, 80, 4, $white);
imagesetpixel($image, 65, 12, $white);

header('Content-type: image/png');
ImagePNG($image);
imagedestroy($image);
?>
[/code]
Tym sposobem postawiliśmy na obrazie kilka małych "kropek":

Oczywiście takich modyfikacji nie wykonuje się ręcznie dla każdego piksela oddzielnie - do tego buduje się funkcje i pętle robiące to "hurtowo". Zaprezentowałem tutaj jedynie prosty przykład mający na celu pokazać, że funkcja taka istnieje i jak jej używać. Przy wykorzystaniu faktu pobierania wartości dowolnych pikseli i ustawiania im własnych wartości można uzyskać naprawdę rozudowane możliwości. Zachęcam do eksperymentowania we własnym zakresie.

[PHP][GD2] Manipulacje obrazami

2015-05-28T03:34:00.002+02:00

Dzięki bibliotece GD możemy manipulować dowolnymi obrazami zapisanymi w formatach JPEG, PNG, GIF i BMP. Możemy dokonywać na nich operacji takich samych jakie robiliśmy w poprzednich artykułach, a więc rysować po nich, pisać, a także łączyć je, skalować, obracać i wiele innych rzeczy. W artykule tym nauczymy się wczytywania obrazków z plików, manipulacji na nich, takich jak skalowanie, czy dodawanie do nich innej grafiki, a także zapisywania wygenerowanych i zmodyfikowanych obrazów do pliku. Warto dokładnie zapoznać się choćby z podstawowymi funkcjami służącymi do manipulacji grafiką, tak aby móc następnie wykorzystywać to w praktyce, np. podczas generowania, czy tworzenia miniaturek dla zdjęć, bądź dodawania znaków wodnych do zdjęć. Zastosowań jest multum, zatem zaczynamy. Na początek nauczymy się wczytywać grafikę z pliku. Jak wspomniałem na początku - mamy tutaj zaimplementowaną obsługę kilku formatów plików. Praca z nimi niczym się od siebie nie różni, używamy do tego jedynie odpowiednio innych funkcji.

ImageCreateFrom() - wczytanie obrazka z pliku

W poprzednich atykułach na samym początku tworzyliśmy uchwyt do pustego obrazka i dopiero potem na nim pracowaliśmy, rysując figury jak prostokąty, czy elipsy. W tym odcinku zamiast tworzyć pusty obrazek, wczytamy go z pliku JPG. Do wczytania obrazka z pliku służy kilka funkcji, w zależności od tego jaki format ma obrazek, który chcemy wczytać. I tak, np.
[code]
imagecreatefromjpeg($nazwa_pliku) //wczytuje obrazek z pliku JPG
imagecreatefrompng($nazwa_pliku) //wczytuje obrazek z pliku PNG
imagecreatefromgif($nazwa_pliku) //wczytuje obrazek z pliku GIF
imagecreatefrombmp($nazwa_pliku) //wczytuje obrazek z pliku BMP
[/code]

Na początek naszej pracy pobierzmy sobie dwa poniższe zdjęcia do testów i zapiszmy sobie je w folderze, w którym pisać będziemy nasz kod. Żeby nam się przyjemnie pracowało, to na obu mamy 2 piękne panie :)

zdjęcie #1: angelina.jpg

oraz

zdjęcie #2: monica.jpg

Gdy mamy oba zdjęcia zapisane w naszym folderze, wczytajmy pierwsze zdjęcie do naszego kodu:
[code]
<?php
$image = imagecreatefromjpeg('angelina.jpg');
?>
[/code]
Tym sposobem wczytane zdjęcie znajduje się teraz w naszym uchwycie (w poprzednich artykułach mieliśmy tutaj pusty obrazek). Możemy to sprawdzić. Jak widzimy zdjęcie jest w formacie JPG, wyświetlmy je zatem jako PNG:
[code]
<?php
$image = imagecreatefromjpeg('angelina.jpg');
// wczytujemy zdjęcie do uchwytu

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyt do obrazka
?>
[/code]
Jak widać, dokonaliśmy nieświadomie pierwszej manipulacji, mianowicie konwersji z formatu JPG na format PNG.

ImageCopyResized() - skalowanie obrazu

Do przeskalowania gotowego obrazka służy funkcja:
[code]imagecopyresized($new_image, $source_image, $new_x, $new_y, $source_x, $source_y, $new_width, $new_height, $source_width, $source_height);[/code]

Jak widać składnia jest dość długa, ale powoli wytłumaczymy sobie wszystko.
Funkcja ta powoduje skopiowanie jednego obrazka do drugiego (jak widzimy będziemy musieli tutaj utworzyć drugi uchwyt do nowego obrazka) pobierając za parametry informacje takie jak wielkość obrazka źródłowego oraz wielkość jaką chcemy uzyskać.
Wyjaśnijmy sobie może najpierw wszystkie argumenty funkcji po koleji:

$new_image - uchwyt do nowo tworzonego obrazu
$source_image - uchwyt do obrazu źródłowego (nasza Angelina)
$new_x - współrzędna X od której zaczniemy nowy obrazek
$new_y - współrzędna Y od której zaczniemy nowy obrazek
$source_x - współrzędna X od której kopiujemy stary obrazek
$source_y - współrzędna Y od której kopiujemy stary obrazek
$new_width - szerokosć nowego obrazka
$new_height - wysokość nowego obrazka
$source_width - szerokosć obrazka źródłowego
$source_height - wysokość obrazka źródłowego

Wyjaśnienia tutaj wymagają wymagane współrzędne X i Y.
Na czym to polega? Otóż kopiowanie starego obrazka może odbyć się od zadanego miejsca. Podając tutaj (x=0, y=0) rozpoczniemy kopiowanie obrazu źródłowego od jego początku, podając jednak np. x=200, y=200 rozpoczniemy właśnie od tego miejsca.

Rozmiar źródłowego obrazu możemy w każdej chwili pobrać za pomocą funkcji:
[code]$width = imagesx($image) // szerokość[/code]
oraz
[code]$height = imagesy($image) // wysokosć[/code]

Zobaczmy działanie na przykładzie, najpierw skopiujmy całość nie zmieniając żadnych rozmiarów i zostawiając wszystkie parametry na domyślne. Rozdzielczość zdjęcia z Angeliną to: 760x360px.
[code]
<?php
$image = imagecreatefromjpeg('angelina.jpg');
// wczytujemy zdjęcie do uchwytu

$image_width = imagesx($image);
$image_height = imagesy($image);
// pobieramy rozmiar oryginalnego obrazu

$new_width = 760;
$new_height = 360;
// definiujemy rozmiar dla nowego obrazu

$new_image = imagecreatetruecolor($new_width, $new_height);
// tworzymy uchwyt dla nowego obrazu

imagecopyresized($new_image, $image, 0, 0, 0, 0, $new_width, $new_height, $image_width, $image_height);
// kopiujemy, narazie bez zmiany parametrów

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($new_image);
// generujemy obrazek PNG

imagedestroy($new_image);
imagedestroy($image);
// zwalniamy uchwyty do obrazków
?>
[/code]

Wynkiem jest to, że oba zdjęcia (źródłowe i docelowe) niczym się nie różnią:

A teraz zmieńmy punkt początkowy (na obrazie docelowym), od którego będziemy nakładać skopiowany z pliku źródłowego obrazek, czyli $new_x i $new_y i zobaczmy co się stanie.
Rozpoczynamy kopiowanie od punktu x=0, y=0, ale nanosimy kopię od punktu x=200, y=120 na nowym zdjęciu:
[code]imagecopyresized($new_image, $image, 200, 150, 0, 0, $new_width, $new_height, $image_width, $image_height);[/code]
Wynik:

Teraz zmieńmy punkt początkowy, od którego kopiować będziemy obrazek źródłowy.
[code]imagecopyresized($new_image, $image, 0, 0, 200, 120, $new_width, $new_height, $image_width, $image_height);[/code]

I w ostatnim przykładzie zmieńmy zarówno jedno jak i drugie:
Rozpoczynamy kopiowanie od punktu x=200, y=120 i nanosimy kopię od punktu x=100, y=150 na nowym zdjęciu:
[code]imagecopyresized($new_image, $image, 100, 150, 200, 120, $new_width, $new_height, $image_width, $image_height);[/code]

Jak widać, zmiana punktu początkowego zarówno w jednym jak i drugim zdjęciu przynosi różne efekty. Sprawdźmy teraz co się stanie podczas skalowania zdjęcia. Standardowo na początek pozostawmy wszystkie punkty początkowe w miejscach (0,0) ale teraz zmieńmy rozdzielczość obrazu wynikowego, np. na 380x180 czyli o połowę:
[code]imagecopyresized($new_image, $image, 0, 0, 0, 0, 380, 180, $image_width, $image_height);[/code]
Wynikiem jest:

Jak widać Angelina zmniejszyła nam się o połowę, ale rozmiar obrazu to wciąż 760x360px, dlaczego? Stało się tak z prostego powodu - na samym początku zadeklarowaliśmy taką właśnie wielkość dla nowego obrazu:
[code]$new_width = 760;
$new_height = 360;
$new_image = imagecreatetruecolor($new_width, $new_height);
[/code]

Natomiast w funkcji imagecopyresized parametry te wpisaliśmy ręcznie, w związku z czym obrazek zeskalował się poprawnie, ale jego bazowa wielkość pozostała bez zmian.
Zmieńmy to więc na 380x180 i zobaczmy co sie stanie:
[code]
<?php
$image = imagecreatefromjpeg('angelina.jpg');
// wczytujemy zdjęcie do uchwytu

$image_width = imagesx($image);
$image_height = imagesy($image);
// pobieramy rozmiar oryginalnego obrazu

$new_width = 380;
$new_height = 180;
// definiujemy rozmiar dla nowego obrazu

$new_image = imagecreatetruecolor($new_width, $new_height);
// tworzymy uchwyt dla nowego obrazu

imagecopyresized($new_image, $image, 0, 0, 0, 0, $new_width, $new_height, $image_width, $image_height);
// kopiujemy, skalujemy

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($new_image);
// generujemy obrazek PNG

imagedestroy($new_image);
imagedestroy($image);
// zwalniamy uchwyty do obrazków
?>
[/code]

Jak widzimy - teraz dopiero zdjęcie zmniejszyło się o połowę do rozmiaru 380x180px.
Należy zawsze o tym pamiętać - rozmiar wynikowego obrazka będzie zawsze rozmiaru zadeklarowanego podczas tworzenia uchwytu do niego!

Spróbójmy teraz czegoś innego - spróbujmy powiększyć wybrany fragment zdjęcia. Jak tego dokonać? Załóżmy, że rozmiar zdjęcia wynikowego ma być taki sam jak zdjęcia oryginalnego, ale ma się w nim znaleźć powiększony fragment oryginału. Po pierwsze całą operację musimy zacząć od zadanego miejsca na obrazku źródłowym ustawiając startowe współrzędne X i Y. Po drugie - szerokość i wysokość zdjęcia podawana w funkcji imagecopyresized musi być odpowiednio większa i po trzecie - na zdjęciu wynikowym nakładamy skopiowanie zdjęcie od punktu (0, 0). Zobaczmy jak to zadziała w praktyce. Spróbujmy powiększyć oczy, czyli obszar mniej więcej od x=220, y=110. Powiększymy wszystko o 400% - wartość o ile razy powiększamy obraz określimy sobie w zmiennych $zoom_x i $zoom_y.

[code]
<?php
$image = imagecreatefromjpeg('angelina.jpg');
// wczytujemy zdjęcie do uchwytu

$image_width = imagesx($image);
$image_height = imagesy($image);
// pobieramy rozmiar oryginalnego obrazu

$zoom_x = 4;
$zoom_y = 4;
// o ile razy powiększamy zdjęcie

$new_width = $image_width * $zoom_x;
$new_height = $image_height * $zoom_y;
// definiujemy rozmiar dla nowego obrazu

$new_image = imagecreatetruecolor(760, 360);
// tworzymy uchwyt dla nowego obrazu, pozostawiamy rozmiar oryginału

imagecopyresized($new_image, $image, 0, 0, 220, 110, $new_width, $new_height, $image_width, $image_height);
// kopiujemy, powiększamy

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($new_image);
// generujemy obrazek PNG

imagedestroy($new_image);
imagedestroy($image);
// zwalniamy uchwyty do obrazków
?>
[/code]

Wynik:

ImageCopyResampled()

Identycznie do funkcji imagecopyresized() działa bliźniacza funkcja:
[code]imagecopyresampled()[/code]
Z tą jednak różnicą, iż w przypadku tej drugiej wartości pixeli są interpolowane, co może poprawić nieznacznie jakość wynikowego obrazu.
Składnia tej funkcji jest identyczna jak funkcji imagecopyresized().

ImageCopy()

Istnieje też zwykła funkcja ImageCopy(), która różni się tym, że - jak sama nazwa wskazuje - nie dokonuje przekształceń na rozmiarze, lecz jedynie kopiuje jeden obraz na drugi. Składnia jest podobna, nie występuje w niej jedynie podawanie argumentów dotyczących rozmiaru obrazu docelowego:

[code]imagecopy($new_image, $source_image, $new_x, $new_y, $source_x, $source_y, $source_width, $source_height);[/code]

ImageRotate() - rotacja zdjęcia

Do obracania obrazu o zadany kąt służy funkcja:
[code]$new_image = imagerotate($image, $angle, $bg_color)[/code]
gdzie:

$image - uchwyt do obrazka
$angle - kąt o jaki obracamy
$bg_color - kolor tła

Powróćmy zatem do pierwotnej wersji naszej Angeliny i spróbujmy obrócić ją o kąt 90 stopni:
[code]
<?php
$image = imagecreatefromjpeg('angelina.jpg');

$new_image = imagerotate($image, 90, 0);
// obracamy Angelinę o 90 stopni w lewo

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($new_image);
// generujemy obrazek PNG
imagedestroy($new_image);
imagedestroy($image);
// zwalniamy uchwyty
?>
[/code]
Wynik:

Uwaga - obracanie działa przeciwnie do ruchu wskazówek zegara, czyli w lewo, aby obrócić w prawo - podajemy minusową wartość kąta.

Rysowanie po obrazie

Tak samo jak w przypadku obrazu utworzonego za pomocą funkcji imagecreatetruecolor() tak i w przypadku wczytanego pliku graficznego mamy do dyspozycji wszystkie związane z generowaniem grafiki funkcje. Żeby zobaczyć jak sprawdza się to w połączeniu z gotowym zdjęciem narysujmy naszej Angelinie okulary. Zrobimy to za pomocą funkcji rysującej elipsę, czyli:
[code]imagefilledellipse()[/code]
rysując dwie elipsy koloru czarnego, o średnicy 70px, następnie dodając wygenerowany tekstowy podpis na samym dole zdjęcia (koloru białego).
Punkty centralne dla elips umieścimy odpowiednio w miejscach:

Elipsa 1: $cx1 = 290, $cxy = 160;
Elipsa 2: $cx2 = 390, $cy2 = 160;

Dodamy też dwie linie o następujących współrzędnych:

Linia 1: x1=325, y1=160, x2=355, y2=160
Linia 2: x1=425, y1=160, x2=460, y2=170

[code]
<?php
$image = imagecreatefromjpeg('angelina.jpg');
// wczytujemy zdjęcie do uchwytu

$black = imagecolorallocatealpha($image, 0, 0, 0, 20);
// zdefiniowaliśmy kolor czarny

$white = imagecolorallocate($image, 255, 255, 255);
// zdefiniowaliśmy kolor biały

imagefilledellipse($image, 290, 160, 70, 70, $black);
// rusujemy prawy okular

imagefilledellipse($image, 390, 160, 70, 70, $black);
// rysujemy lewy okular

imageline($image, 325, 160, 355, 160, $black);
// rysujemy linię pomiędzy okularami

imageline($image, 425, 160, 460, 170, $black);
// rysujemy linię od lewego okulara do lewego ucha

imagestring($image, 5, 25,340, "photoshoped by GD2 :)", $white);

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyty do obrazków
?>
[/code]
Oto wynik ;)

Wszystko poza samą Angeliną zostało tutaj wygenerowane za pomocą PHP.

ImageFilter() - filtry

Posłużymy się teraz naszym drugim zdjęciem i zobaczymy co oferują filtry w GD2.
Dzięki filtrom zaaplikować możemy do zdjęcia kilka standardowych efektów, takich jak utworzenie z niego negatywu, czy desaturacja. Przyjrzyjmy się po krótce wszystkim dostępnym możliwościom, ale najpierw wczytajmy oryginalne zdjęcie:
[code]
<?php
$image = imagecreatefromjpeg('monica.jpg');
// wczytujemy zdjęcie do uchwytu

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyty do obrazków
?>
[/code]

Filtry nakładamy za pomocą funkcji:
[code]imagefilter($image, $filter, $arg1, $arg2, $arg3, $arg4)[/code]
gdzie

$image - uchwyt do obrazka
$filter - rodzaj filtra
$arg1-4 - argumenty dla odpowiednich filtrów,

pełny opis tutaj: http://php.net/manual/en/function.imagefilter.php

Na chwilę obecną dostępne mamy następujące rodzaje filtrów:

IMG_FILTER_NEGATE: tworzy negatyw z obrazu
IMG_FILTER_GRAYSCALE: konwertuje obraz na odcienie szarości
IMG_FILTER_BRIGHTNESS: Zmienia jasność obrazu (definiowana w $arg1)
IMG_FILTER_CONTRAST: zmienia kontrast obrazu (definiowany w $arg1)
IMG_FILTER_COLORIZE: kolorozyje obraz, wartości RGB podajemy odpowiednio w $arg1, $arg2, $arg3
IMG_FILTER_EDGEDETECT: uwypukla krawędzie
IMG_FILTER_EMBOSS: dodaje filtr embros, który "uwypukla" obraz
IMG_FILTER_GAUSSIAN_BLUR: dodaje rozmycie metodą Gaussa
IMG_FILTER_SELECTIVE_BLUR: rozmywa obraz
IMG_FILTER_MEAN_REMOVAL: tworzy coś w rodzaju szkicu
IMG_FILTER_SMOOTH: wygładza obraz, wartość wygładzenia podajemy w $arg1
IMG_FILTER_PIXELATE: dodaje pixelizację, wartości podajemy w $arg1 i $arg2

Przyjrzyjmy się pierwszemu filtrowi, czyli zróbmy sobie negatyw:
[code]
<?php
$image = imagecreatefromjpeg('monica.jpg');
// wczytujemy zdjęcie do uchwytu

imagefilter($image, IMG_FILTER_NEGATE);
// aplikujemy filtr

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyt do obrazu
?>
[/code]
Wynik:

I kolejne filtry:

[code]imagefilter($image, IMG_FILTER_GRAYSCALE);[/code]

[code]imagefilter($image, IMG_FILTER_BRIGHTNESS, 130);[/code]

[code]imagefilter($image, IMG_FILTER_BRIGHTNESS, -150);[/code]

[code]imagefilter($image, IMG_FILTER_CONTRAST, -50);[/code]

[code]imagefilter($image, IMG_FILTER_CONTRAST, 50);[/code]

[code]imagefilter($image, IMG_FILTER_COLORIZE, 255, 0, 0);[/code]

[code]imagefilter($image, IMG_FILTER_COLORIZE, 0, 0, 128);[/code]

[code]imagefilter($image, IMG_FILTER_EDGEDETECT);[/code]

[code]imagefilter($image, IMG_FILTER_EMBOSS);[/code]

[code]imagefilter($image, IMG_FILTER_GAUSSIAN_BLUR);[/code]

[code]imagefilter($image, IMG_FILTER_SELECTIVE_BLUR);[/code]

[code]imagefilter($image, IMG_FILTER_MEAN_REMOVAL);[/code]

[code]imagefilter($image, IMG_FILTER_SMOOTH, 8);[/code]

[code]imagefilter($image, IMG_FILTER_PIXELATE, 2, 8);[/code]

Jak widać, biblioteka GD pozwala na całkiem przyzwoite efekty.

ImageMerge() - łączenie obrazków.

Pozostała nam do omówienia jeszcze jedna bardzo często wykorzystywana w GD2 kwestia, mianowicie łączenie ze sobą obrazków. Wyobraźmy sobie, że chcemy np. dodać graficzny znak wodny do danego zdjęcia, lub nałożyć jedno zdjęcie na drugie. Jak tego dokonać? Zacznijmy może prostego nałożenia jednego obrazka na drugi. Spróbujemy nałożyć obraz z Monicą Bellucci na obraz z Angeliną Jolie.

Posłuży nam do tego funkcja:
[code]imagecopymerge($image, $image_to_add, $image_x, $image_y, $image_to_add_x, $image_to_add_y, $image_to_add_width, $image_to_add_height, $opacity);[/code]
gdzie:

$image - uchwyt do bazowego obrazka (Angelina) - ten obrazek będzie pod spodem
$image_to_add - uchwyt do obrazu który będziemy nakładać (Monica) - ten obrazek nałożymy
$image_x - współrzędna X bazowego obrazka (Angelina) od której nakładany na nią drugi obraz (Monica)
$image_y - współrzędna Y bazowego obrazka (Angelina) od której nakładany na nią drugi obraz (Monica)
$image_to_add_x - współrzędna X nakładanego obrazu od której zaczynamy nakładanie (Monica)
$image_to_add_y - współrzędna Y nakładanego obrazu od której zaczynamy nakładanie (Monica)
$image_to_add_width - szerokosć nakładanego obrazka (Monica)
$image_to_add_height - wysokość nakładaneg obrazka (Monica)
$opacity - stopień przezroczystości nakładanego obrazka

Najepiej zobaczmy to na przykładzie:
[code]
<?php
$image = imagecreatefromjpeg('angelina.jpg');
$image_to_add = imagecreatefromjpeg('monica.jpg');

$image_x = 15;
// współrzędna X bazowego obrazka (Angelina) od której nakładany na nią drugi obraz (Monica)

$image_y = 195;
// współrzędna Y bazowego obrazka (Angelina) od której nakładany na nią drugi obraz (Monica)

$image_to_add_x = 95;
// współrzędna X nakładanego obrazu od której zaczynamy nakładanie (Monica)

$image_to_add_y = 75;
// współrzędna Y nakładanego obrazu od której zaczynamy nakładanie (Monica)

$image_to_add_width = 150;
// szerokosć nakładanego obrazka (Monica)

$image_to_add_height = 150;
// wysokość nakładaneg obrazka (Monica)

$opacity = 80;
// stopień przezroczystości nakładanego obrazka

imagecopymerge($image, $image_to_add, $image_x, $image_y, $image_to_add_x, $image_to_add_y, $image_to_add_width, $image_to_add_height, 100);
// nakładamy Monicę na Angelinę

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
imagedestroy($image_to_add);
// zwalniamy uchwyty do obrazków
?>
[/code]

Przeanalizujmy po koleji:
Nakładać będziemy zdjęcie z Monicą.
Nałożymy część jej zdjęcia, która zaczyna się od współrzędnych:

$image_to_add_x = 95px
$image_to_add_y = 75px

Obszar nakładany będzie miał rozmiar:

$image_to_add_width = 150px
$image_to_add_height = 150px

Następnie wybrany obszar nakładać będziemy na zdjęcie Angeliny, począwszy od współrzędnych:

$image_x = 15px;
$image_y = 195px;

Co w efekcie da nam takie oto zdjęcie:

Dodając trochę więcej przeźroczystości:
[code]$opacity = 80[/code]
otrzymamy natomiast coś w rodzaju znaku wodnego:

Jak widać nie jest to takie trudne.
Została nam jeszcze jedna kwestia:

Zapis obrazu do pliku

Jak do tej pory generowaliśmy obraz bezpośrednio do przeglądarki, zobaczymy teraz w jaki sposób zapisać zdjęcie do pliku, a jest to bardzo proste i ogranicza się do podania jednego dodatkowego parametru, do którejś z poniższych funkcji:
[code]imagepng($image, "nazwa_pliku");[/code]
[code]imagejpeg($image, "nazwa_pliku");[/code]
[code]imagegif($image, "nazwa_pliku");[/code]
[code]imagebmp($image, "nazwa_pliku");[/code]

Podanie jako drugi parametr nazwy pliku spowoduje zapis obrazu do pliku zamiast wyświetlenia go na ekran.
Przetestujmy:
[code]
<?php
$image = imagecreatefromjpeg('angelina.jpg');

if(imagepng($image, "angelina2.png"))
{
echo 'Image saved to file.';
}
// generujemy i zapisujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyt
?>[/code]

Jak widzimy, wszystko to nie jest takie trudne jak może wydawać się na pierwszy rzut okna.
Zachęcam ponownie do eksperymentowania we własnym zakresie.
W następnych artykułach zajmiemy się czcionkami TrueType, pracą nad kolorami i gradientami oraz jeszcze kilkoma ciekawymi rzeczami.

[PHP][GD2] Rysujemy podstawowe kształty

2015-05-27T21:48:00.002+02:00

Za pomocą biblioteki GD możemy nie tylko rysować prostokąty, lecz tworzyć o wiele bardziej złożone kształty, rysować linie, czy dodawać tekst. Wszystko sprowadza się do podania odpowiednich współrzędnych dla funkcji rysujących, a następnie wygenerowania danego kształtu i wypełnienia go odpowiednim kolorem. Warto poznać kilka podstawowych funkcji, takich jak rysowanie okręgów, czy elips, lub też prowadzenia linii z punku a do punktu. W tej krótkiej części przyjrzymy się najczęściej używanym, podstawowym funkcjom służącym do rysowania na obrazku standardowych kształtów. W poprzedniej części, w podstawach narysowaliśmy prosty prostokąt, tym razem na początek narysujmy sobie elipsę. Wróćmy jednak jeszcze na moment do rysowania wypełnionego prostokąta z poprzedniej części. Użyliśmy tam funkcji:
[code]imagefilledrectangle()[/code]

Z wypełnieniem i bez - filled

Warto wiedzieć, że funkcja ta (jak i jej podobne) posiada także swój odpowiednik rysujący taki sam prostokąt, ale bez wypełniania go kolorem. Funkcje rysujące bez wypełniania kolorem nie zawierają w nazwie "filled", czyli z ang. wypełnienie.
I tak, za pomocą funkcji:
[code]imagerectangle()[/code]
narysujemy sam obrys prostokąta, popatrzmy:
[code]
<?php
$width = 400;
$height = 300;
$image = imagecreatetruecolor($width, $height);
// stworzyliśmy pusty obrazek o szerokości 400px i wysokości 300px

$black = imagecolorallocate($image, 0, 0, 0);
// zdefiniowaliśmy kolor czarny dla tła

$red = imagecolorallocate($image, 255, 0, 0);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $red

imagefill($image, 0, 0, $black);
// wypełniliśmy obszar 400x300px naszego obrazka kolorem pobranym ze zmiennej $black

imagerectangle($image, 20, 20, 100, 120, $red);
// wypełniliśmy obszar od 20-100px w poziomie i 20-120px w pionie

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyt do obrazka
?>
[/code]
Wynikiem jest niewypełniony prostokąt, w tym przypadku wartość koloru została wykorzystana do określenia koloru obrysu.

Analogicznie będzie z wszystkimi pozostałymi funkcjami jakie tutaj poznamy - wszystkie one posiadają wersję wypełniające tło i niewypełniające go.

ImageFilledEllipse() - rysujemy elipsę

Narysujmy teraz elipsę, albo nawet dwie, lub trzy. Służy do tego funkcja:
[code]imagefilledellipse($image, $cx, $cy, $width, $height, $color);[/code]
gdzie:

$image - uchwyt naszego obrazka
$cx = punkt środkowy elipsy w osi X
$cy = punkt środkowy elipsy w osi Y
$width - szerokość elipsy
$height - wysokość elipsy
$color - kolor wypełnienia

Przygotujmy dodatkowe kolory, tym razem zielony i biały i narysujmy trzy elipsy, z czego elipsa zielona będzie o kształcie koła (taka sama szerokość i wysokość), a biała nie będzie posiadac wypełnienia:

[code]
<?php
$width = 400;
$height = 300;
$image = imagecreatetruecolor($width, $height);
// stworzyliśmy pusty obrazek o szerokości 400px i wysokości 300px

$black = imagecolorallocate($image, 0, 0, 0);
// zdefiniowaliśmy kolor czarny dla tła

$red = imagecolorallocate($image, 255, 0, 0);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $red

$white = imagecolorallocate($image, 255, 255, 255);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $red

$green = imagecolorallocate($image, 0, 255, 0);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $green

imagefill($image, 0, 0, $black);
// wypełniliśmy obszar 400x300px naszego obrazka kolorem pobranym ze zmiennej $black

imagefilledellipse($image, 200, 200, 100, 120, $red);
// #1 rysujemy pierwszą elipsę (czerwoną), o środku w punkcie 200x200 i szerokości 100x120px

imagefilledellipse($image, 300, 80, 100, 100, $green);
// #2 rysujemy drugą elipsę (zieloną), o środku w punkcie 300x80 i szerokości 100x100px

imageellipse($image, 50, 50, 40, 40, $white);
// #3 rysujemy trzecią elipsę (białą), bez wypełnienia o środku w punkcie 50x50 i szerokości 40x40px

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyt do obrazka
?>
[/code]

Wynik:

Jak widać rysowanie elipsy jest zbliżone do rysowania prostokąta, z tym, że tutaj podajemy punkty środkowe i szerokość/wysokość zamiast współrzędnych początkowych i końcowych.

ImageLine() - rysujemy linie

Poprowadzimy teraz linię, którą rysuje się za pomocą następującej funkcji:
[code]imageline($image, $x1, $y1, $x2, $y2, $color);[/code]
gdzie:

$image - uchwyt do obrazka
$x1 - punkt początkowy na osi X
$y1- punkt początkowy na osi Y
$x2 - punkt końcowy na osi X
$y2- punkt końcowy na osi Y
$color - kolor linii

Jak widać skadnia identyczna jak podczas rysowania prostokąta.

Naszą linię poprowadźmy od środka czerwonej elipsy do środka elipsy zielonej, a więc podawając jako x1 i y1 współrzędne środka czerwonej elipsy, a jako x2 i y2 współrzędne środka elipsy zielonej.
Nasza linia będzie niebieska, a więc utworzymy kolejny kolor, tym razem niebieski.

[code]
<?php
$width = 400;
$height = 300;
$image = imagecreatetruecolor($width, $height);
// stworzyliśmy pusty obrazek o szerokości 400px i wysokości 300px

$black = imagecolorallocate($image, 0, 0, 0);
// zdefiniowaliśmy kolor czarny dla tła

$red = imagecolorallocate($image, 255, 0, 0);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $red

$white = imagecolorallocate($image, 255, 255, 255);
// zdefiniowaliśmy kolor biały i zapisaliśmy go do zmiennej $white

$green = imagecolorallocate($image, 0, 255, 0);
// zdefiniowaliśmy kolor zielony i zapisaliśmy go do zmiennej $green

$blue = imagecolorallocate($image, 0, 0, 255);
// zdefiniowaliśmy kolor niebieski zapisaliśmy go do zmiennej $blue

imagefill($image, 0, 0, $black);
// wypełniliśmy obszar 400x300px naszego obrazka kolorem pobranym ze zmiennej $black

imagefilledellipse($image, 200, 200, 100, 120, $red);
// #1 rysujemy pierwszą elipsę (czerwoną), o środku w punkcie 200x200 i szerokości 100x120px

imagefilledellipse($image, 300, 80, 100, 100, $green);
// #2 rysujemy drugą elipsę (zieloną), o środku w punkcie 300x80 i szerokości 100x100px

imageellipse($image, 50, 50, 40, 40, $white);
// #3 rysujemy trzecią elipsę (białą), bez wypełnienia o środku w punkcie 50x50 i szerokości 40x40px

imageline($image, 200, 200, 300, 80, $blue);
// #4 rysujemy linię ze środka elipsy czerwonej (200, 200) do środka elipsy zielonej (300, 80)

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyt do obrazka
?>
[/code]

Wynik:

Prawda, że proste?

ImageFilledPolygon() - rysujemy poligony

Narysujmy teraz poligon. Tutaj jest ciekawa sprawa, ponieważ w tym przypadku możemy podać dowolną ilość punktów, a robimy to za pomocą tablicy. Popatrzmy jak wygląda składnia funkcji rysującej poligon złożony z dowolnej ilości punktów:
[code]imagefilledpolygon($image, $tablica_współrzędnych_punktów, $ilość_punktów, $kolor)[/code]
gdzie:

$image - uchwyt do obrazka
$tablica_współrzędnych_punktów - tablica ze wszystkimi współrzędnymi,np.
[code]
array(
10, 10, //punkt pierwszy x, y
10,30, //punkt drugi x, y
30,80 //punkt trzeci x, y
)
[/code]
$ilość_punktów - musi odpowiadać ilości punktów podanych w tablicy
$kolor - kolor wypełnienia

Zrezygnujmy z naszej linii i narysujmy tym razem poligon składający się z trzech punktów, które będą środkami naszych wszystkich trzech okręgów.
Żeby tym razem się nie powtarzać z wartościami, współrzędne dla okręgów (i naszego poligonu) określimy sobie w zmiennych $cx1, $cx2...itd
[code]
<?php
$width = 400;
$height = 300;
$image = imagecreatetruecolor($width, $height);
// stworzyliśmy pusty obrazek o szerokości 400px i wysokości 300px

// współrzędne środków okręgów:
$cx1 = 200; // czerwony X
$cy1 = 200; // czerwony Y

$cx2 = 300; // zielony X
$cy2 = 80; // zielony Y

$cx3 = 50; // biały X
$cy3 = 50; // biały Y

// punkty dla poligonu:
$polygon_points = array(
$cx1, $cy1,
$cx2, $cy2,
$cx3, $cy3
);

$black = imagecolorallocate($image, 0, 0, 0);
// zdefiniowaliśmy kolor czarny dla tła

$red = imagecolorallocate($image, 255, 0, 0);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $red

$white = imagecolorallocate($image, 255, 255, 255);
// zdefiniowaliśmy kolor biały i zapisaliśmy go do zmiennej $white

$green = imagecolorallocate($image, 0, 255, 0);
// zdefiniowaliśmy kolor zielony i zapisaliśmy go do zmiennej $green

$blue = imagecolorallocate($image, 0, 0, 255);
// zdefiniowaliśmy kolor niebieski zapisaliśmy go do zmiennej $blue

imagefill($image, 0, 0, $black);
// wypełniliśmy obszar 400x300px naszego obrazka kolorem pobranym ze zmiennej $black

imagefilledellipse($image, $cx1, $cy1, 100, 120, $red);
// #1 rysujemy pierwszą elipsę (czerwoną), o środku w punkcie 200x200 i szerokości 100x120px

imagefilledellipse($image, $cx2, $cy2, 100, 100, $green);
// #2 rysujemy drugą elipsę (zieloną), o środku w punkcie 300x80 i szerokości 100x100px

imageellipse($image, $cx3, $cy3, 40, 40, $white);
// #3 rysujemy trzecią elipsę (białą), bez wypełnienia o środku w punkcie 50x50 i szerokości 40x40px

imagefilledpolygon($image, $polygon_points, 3, $blue);
// rysujemy polygon z tzrech punktów

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyt do obrazka
?>
[/code]

Oto wynik naszego działania:

Prawda, że proste?

ImageFilledArc() - rysujemy wypełnienie kołowe

Narysujmy teraz coś bardziej skomplikowanego - wypełnienie kątowe.
Stworzy nam to cząstkę okręgu opartą na zadanych kącie, co jest przydatne w generowaniu wykresów kołowych.
Funkcja do tego służąca to:
[code]imagefilledarc($image, $cx, $cy, $width, $height, $start_angle, $end_angle, $color, $styl);[/code]
gdzie:

$image - uchwyt naszego obrazka
$cx = punkt środkowy elipsy w osi X
$cy = punkt środkowy elipsy w osi Y
$width - szerokość elipsy
$height - wysokość elipsy
$start_angle - kąt początkowy (w stopniach)
$end_angle - kąt końcowy (w stopniach)
$color - kolor wypełnienia
$styl - określa sposób łączenia punktu początkowego z końcowym, możliwe parametry:
IMG_ARC_PIE - łączenie kołowe
IMG_ARC_CHORD - łączenie linią prostą
IMG_ARC_NOFILL - bez wypełnienia
IMG_ARC_EDGED - daje jedynie obrys całości.

Zrezygnujemy teraz z naszych elips i w ich miejsce narysujemy sobie nasze "arców"

[code]
<?php
$width = 400;
$height = 300;
$image = imagecreatetruecolor($width, $height);
// stworzyliśmy pusty obrazek o szerokości 400px i wysokości 300px

// współrzędne środków okręgów:
$cx1 = 200; // czerwony X
$cy1 = 200; // czerwony Y

$cx2 = 300; // zielony X
$cy2 = 80; // zielony Y

$cx3 = 50; // biały X
$cy3 = 50; // biały Y

$black = imagecolorallocate($image, 0, 0, 0);
// zdefiniowaliśmy kolor czarny dla tła

$red = imagecolorallocate($image, 255, 0, 0);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $red

$white = imagecolorallocate($image, 255, 255, 255);
// zdefiniowaliśmy kolor biały i zapisaliśmy go do zmiennej $white

$green = imagecolorallocate($image, 0, 255, 0);
// zdefiniowaliśmy kolor zielony i zapisaliśmy go do zmiennej $green

$blue = imagecolorallocate($image, 0, 0, 255);
// zdefiniowaliśmy kolor niebieski zapisaliśmy go do zmiennej $blue

imagefill($image, 0, 0, $black);
// wypełniliśmy obszar 400x300px naszego obrazka kolorem pobranym ze zmiennej $black

imagefilledarc($image, $cx1, $cy1, 100, 120, 0, 180, $red, IMG_ARC_PIE);
// #1 rysujemy wypełnienie koła (czerwone), o środku w punkcie 200x200 i szerokości 100x120px, zaczynając od kąta 0, do kąta 180

imagefilledarc($image, $cx2, $cy2, 100, 100, 0, 90, $green, IMG_ARC_CHORD);
// #2 rysujemy wypełnienie koła (zielone), o środku w punkcie 300x80 i szerokości 100x100px, zaczynając od kąta 0, do kąta 90

imagearc($image, $cx3, $cy3, 40, 40, 45, 70, $white);
// #3 rysujemy koło (białe), bez wypełnienia, o środku w punkcie 50x50 i szerokości 40x40px, zaczynając od kąta 45, do kąta 70

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyt do obrazka
?>
[/code]

Wynik:

ImageChar() - dołączamy znak

Ostatnią rzeczą jaką omówimy w tym artykule jest rysowanie tekstu. Narazie wykonamy to prostą metodą, a w następnych artykułach nauczymy się wykorzystywac do tego zewnętrzne czcionki TrueType.
Pojedyńczy znak na obrazku generujemy za pomocą funkcji:
[code]imagechar($image, $font_size, $x, $y, $char, $color);[/code]
gdzie:

$image - uchwyt do obrazka
$font_size - rozmiar czcionki od 1 do 5
$x - współrzędna na osi X
$y - współrzędna na osi Y
$char - znak do napisania na obrazku
$color - kolor czcionki

Za pomocą funkcji:
[code]imagecharup($image, $font_size, $x, $y, $char, $color);[/code]
dokonamy tego samego, tyle że w pionie.

Przetestujmy jak to działa:
[code]
<?php
$width = 400;
$height = 300;
$image = imagecreatetruecolor($width, $height);
// stworzyliśmy pusty obrazek o szerokości 400px i wysokości 300px

$black = imagecolorallocate($image, 0, 0, 0);
// zdefiniowaliśmy kolor czarny dla tła

$red = imagecolorallocate($image, 255, 0, 0);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $red

$white = imagecolorallocate($image, 255, 255, 255);
// zdefiniowaliśmy kolor biały i zapisaliśmy go do zmiennej $white

$green = imagecolorallocate($image, 0, 255, 0);
// zdefiniowaliśmy kolor zielony i zapisaliśmy go do zmiennej $green

$blue = imagecolorallocate($image, 0, 0, 255);
// zdefiniowaliśmy kolor niebieski zapisaliśmy go do zmiennej $blue

imagefill($image, 0, 0, $black);
// wypełniliśmy obszar 400x300px naszego obrazka kolorem pobranym ze zmiennej $black

imagechar($image, 5, 10, 10, "P", $red);
imagechar($image, 5, 50, 50, "H", $green);
imagechar($image, 5, 100, 100, "P", $blue);

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyt do obrazka
?>
[/code]
Wynik:

ImageString() - dołączamy tekst

A teraz to samo, ale nie z pojedyńczym znakiem, ale z całym stringiem, służy do tego funkcja:
[code]imagestring($image, $font_size, $x, $y, $string, $color);[/code]
gdzie:

$image - uchwyt do obrazka
$font_size - rozmiar czcionki od 1 do 5
$x - współrzędna na osi X
$y - współrzędna na osi Y
$string - ciąg znaków do napisania na obrazku
$color - kolor czcionki

Sprawdżmy w praktyce:
[code]
<?php
$width = 400;
$height = 300;
$image = imagecreatetruecolor($width, $height);
// stworzyliśmy pusty obrazek o szerokości 400px i wysokości 300px

$black = imagecolorallocate($image, 0, 0, 0);
// zdefiniowaliśmy kolor czarny dla tła

$red = imagecolorallocate($image, 255, 0, 0);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $red

$white = imagecolorallocate($image, 255, 255, 255);
// zdefiniowaliśmy kolor biały i zapisaliśmy go do zmiennej $white

$green = imagecolorallocate($image, 0, 255, 0);
// zdefiniowaliśmy kolor zielony i zapisaliśmy go do zmiennej $green

$blue = imagecolorallocate($image, 0, 0, 255);
// zdefiniowaliśmy kolor niebieski zapisaliśmy go do zmiennej $blue

imagefill($image, 0, 0, $black);
// wypełniliśmy obszar 400x300px naszego obrazka kolorem pobranym ze zmiennej $black

imagestring($image, 2, 10, 10, "PHP", $red);
imagestring($image, 3, 50, 50, "EVERYWHERE", $green);
imagestring($image, 5, 100, 100, "BLOG", $blue);

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyt do obrazka
?>
[/code]
Wynik:

Jak widać korzystanie z wszystkich tych funkcji jest bardzo proste i ogranicza się do poznania ich składni. Funkcji tych jest bardzo dużo, polecam zajrzeć do manuala, który znajduje się tutaj:
http://php.net/manual/en/ref.image.php
W następnych artykułach nauczymy się operacji na obrazkach - wczytywania obrazka z pliku, obracania go, skalowania, aplikowania filtrów i zapisywania na dysk, a także wielu innych rzeczy.

[PHP][GD2] Podstawy generowania grafiki

2015-05-27T19:33:00.001+02:00

Biblioteka GD2 wbudowana w PHP to bardzo rozbudowane narzędzie, pozwalające na generowanie właściwie każdego rodzaju grafiki bitmapowej. Dzięki niej możemy generować grafikę bezpośrednio z poziomu PHP, co za tym idzie również manipulować istniejącą grafiką zapisaną w plikach takich jak JPEG, PNG, czy BMP, a więc tworzyć różnego rodzaju miniaturki, skalować i obracać zdjęcia, nakładać "w locie" filtry, znaki wodne, bądź napisy z zewnętrznych czcionek TrueType. Biblioteka ta nadaje się również świetnie do generowania wszelkiego rodzaju graficznych wykresów reprezentujących dane pobrane bezpośrednio z PHP. Wygenerowane grafiki możemy następnie wyświetlać bezpośrednio do przeglądarki, albo zapisywać do plików. W artykule tym nauczymy się podstawowej zasady działania biblioteki i dowiemy się w jaki sposób wykorzystywać ją w kodzie.

1. ImageCreateTrueColor() - tworzymy pusty obrazek

Pierwszą podstawową rzeczą podczas pracy z GD2 jest stworzenie uchwytu do obrazka. Każda zabawa z GD2 rozpoczyna się od tego. Będziemy operować na pełnej palecie barw, więc nasz obrazek będziemy tworzyć za pomocą funkcji:
[code]$image = imagecreatetruecolor(szerokość_obrazka, wysokość_obrazka)[/code]

Jak widać za jedyne argumenty pobiera ona wysokość oraz szerokość generowanego przez nas obrazu. Stwórzmy nasz pierwszy obrazek:
[code]
<?php
$width = 400;
$height = 300;
$image = imagecreatetruecolor($width, $height);
// stworzyliśmy pusty obrazek o szerokości 400px i wysokości 300px
?>
[/code]
Obrazek nasz zapisaliśmy do zmiennej $image, na której to zmiennej będziemy następnie dokonywać wszystkich zwiazanych z nim operacji. Mamy więc pusty obrazek, który jednak narazie jest jedynie zasobem w pamięci operacyjnej serwera, nic tutaj narazie się nam jeszcze na ekranie nie wyświetli.
Na początek dodajmy mu trochę koloru, wypełnijmy go całego np. kolorem czerwonym.

Do stworzenia obrazu o zwykłej palecie barw służy natomiast funkcja:
[code]$image = imagecreate(szerokość_obrazka, wysokość_obrazka)[/code]

2. ImageCollorAllocate() - definiujemy kolor

Wartość danego koloru musimy najpierw zdefiniować za pomocą funkcji:
[code]$color = imagecolorallocate($image, R, G, B)[/code]
gdzie jako pierwszy parametr podajemy uchwyt do utworzonego wcześniej obrazka, a następnie kolejno wartości RGB tworzonego koloru (z zakresu 0-255).

2.5. ImageCollorAllocateAlpha() - definiujemy kolor z alphą

Możemy także stworzyć kolor z wartością kanału alpha, a więc z przezroczystością, używamy do tego funkcji:
[code]$color = imagecolorallocatealpha($image, R, G, B, Alpha)[/code]
gdzie jako dodatkowy parametr podajemy wartość kanału alpha (z zakresu 0-127)

My chcemy stworzyć kolor czerwony, wywołamy więc funkcję z następującymi argumentami, przy czym zapiszemy sobie nasz kolor do zmiennej $red:
[code]
<?php
$width = 400;
$height = 300;
$image = imagecreatetruecolor($width, $height);
// stworzyliśmy pusty obrazek o szerokości 400px i wysokości 300px

$red = imagecolorallocate($image, 255, 0, 0);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $red
?>
[/code]

3. ImageFill() - wypełniamy obrazek

Mamy już zdefiniowaną wartość koloru, czas aby wypełnić nasz obrazek tym właśnie kolorem, służy do tego funkcja:
[code]imagefill($image, $x, $y, $color)[/code]
gdzie jako pierwszy argument podajemy uchwyt do obrazka, następnie:

$x - punkt początkowy w osi X od którego zaczynamy wypełnianie kolorem
$y - punkt początkowy w osi Y od którego zaczynamy wypełnianie kolorem
$color - wartość koloru wypełnienia utworzona uprzednio za pomocą imagecollorallocate()

My chcemy wypełnić cały obrazek, a więc cały obszar o wielkości 400x300px, jako początkowe współrzędne podamy więc wartości zerowe, a kolorem jakim wypełniamy będzie nasz czerwony:
[code]
<?php
$width = 400;
$height = 300;
$image = imagecreatetruecolor($width, $height);
// stworzyliśmy pusty obrazek o szerokości 400px i wysokości 300px

$red = imagecolorallocate($image, 255, 0, 0);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $red

imagefill($image, 0, 0, $red);
// wypełniliśmy obszar 400x300px naszego obrazka kolorem pobranym ze zmiennej $red
?>
[/code]

4. ImagePNG - wyświetlamy obrazek

Dla sprawdzenia wyniku wyświetlmy teraz obrazek bezpośrednio w przeglądarce.
Służy do tego kilka funkcji, w zależności od tego jakiego typu obrazek chcemy wyrzucić na ekran:
[code]
imagepng($image); - wyświetla nasz obrazek w formacie PNG
imagejpeg($image); - wyświetla nasz obrazek w formacie JPEG
imagebmp($image); - wyświetla nasz obrazek w formacie Windows BMP
imagegif($image); - wyświetla nasz obrazek w formacie GIF
[/code]

Aby jednak wyświetlić obrazek, musimy najpierw wysłać do przeglądarki nagłówek informujący o typie naszego obrazu. Dokonujemy tego za pomocą ustawienia odpowiedniego Mime-Type:

PNG - image/png
JPEG - image/jpeg
BMP - image/bmp
GIF - image/gif

Wyświetlmy nasz obrazek jako PNG:
[code]
<?php
$width = 400;
$height = 300;
$image = imagecreatetruecolor($width, $height);
// stworzyliśmy pusty obrazek o szerokości 400px i wysokości 300px

$red = imagecolorallocate($image, 255, 0, 0);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $red

imagefill($image, 0, 0, $red);
// wypełniliśmy obszar 400x300px naszego obrazka kolorem pobranym ze zmiennej $red

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyt do obrazka
?>
[/code]

W tym momencie powinien nam się wyświetlić piękny czerwony prostokąt o wymiarach 400x300px (wymiary na obrazku dodałem oddzielnie, wy zobaczycie jedynie czerwony prostokąt):

Pamiętajmy, że po wygenerowaniu grafiki zwalniamy zasób za pomocą:
[code]imagedestroy($image);[/code]

Warto też tutaj przyjrzeć się funkcji:
[code]imagefill()[/code]
Otóż - niezależnie jakie w tym momencie podamy koordynaty x i y, to obrazek zostanie wypełniony danym kolorem w całości.

5. ImageFilledRectangle()

Aby wypełnić jedynie zadany przez nas prostokątkny obszar, musimy skorzystać z funkcji:
[code]imagefilledrectangle($image, $x1, $y1, $x2, $y2, $red);[/code]
gdzie:

$x1 - punkt początkowy na osi X
$y1- punkt początkowy na osi Y
$x2 - punkt końcowy na osi X
$y2- punkt końcowy na osi Y

Wypełnijmy teraz więc jedynie jakąś część obrazka:
[code]
<?php
$width = 400;
$height = 300;
$image = imagecreatetruecolor($width, $height);
// stworzyliśmy pusty obrazek o szerokości 400px i wysokości 300px

$black = imagecolorallocate($image, 0, 0, 0);
// zdefiniowaliśmy kolor czarny dla tła

$red = imagecolorallocate($image, 255, 0, 0);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $red

imagefill($image, 0, 0, $black);
// wypełniliśmy obszar 400x300px naszego obrazka kolorem pobranym ze zmiennej $black

imagefilledrectangle($image, 20, 20, 100, 120, $red);
// wypełniliśmy obszar od 20-100px w poziomie i 20-120px w pionie

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyt do obrazka
?>
[/code]

Warto zauważyć, iż x2 i y2 nie oznaczają szerokości i wysokości wypełnienia lecz współrzędne na obrazku:

Współrzędne liczymy zawsze od lewego górnego rogu obrazka, który posiada współrzędną (0, 0).

6. Kanał alpha

Jak teraz utworzyć obrazek z kanałem alpha?
Po pierwsze musimy zdefiniować nasz kolor z takim właśnie kanałem. Robimy to za pomocą funkcji:
[code]$color = imagecolorallocatealpha($image, R, G, B, Alpha)[/code]
gdzie kanał alpha może przyjąć wartości od 0(całkowicie nieprzezroczysty) do 127 (całkowicie przezroczysty)

Stwórzmy więc nasz kolor czerwony, tak aby był w połowie przeźroczysty (wartość alpha - 64):
[code]
<?php
$width = 400;
$height = 300;
$image = imagecreatetruecolor($width, $height);
// stworzyliśmy pusty obrazek o szerokości 400px i wysokości 300px

$black = imagecolorallocate($image, 0, 0, 0);
// zdefiniowaliśmy kolor czarny dla tła

$red = imagecolorallocatealpha($image, 255, 0, 0, 64);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $red, tym razem z kanałem alpha

imagefill($image, 0, 0, $black);
// wypełniliśmy obszar 400x300px naszego obrazka kolorem pobranym ze zmiennej $black

imagefilledrectangle($image, 20, 20, 100, 120, $red);
// wypełniliśmy obszar od 20-100px w poziomie i 20-120px w pionie

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyt do obrazka
?>
[/code]

Wynik:

Jak widać, czerwony prostokąt troche nam przyciemniał, gdyż jest na wpół przezroczysty.
Cały obrazek jednak jako taki jest wciąż całkowicie nieprzeźroczysty. Jak teraz sprawić, aby nasz PNG jako całość uzyskał przezroczystość? Na logikę może się wydawać, że dałoby radę zrobić to za pomocą:
[code]$black = imagecolorallocatealpha($image, 0, 0, 0, 100);[/code]
dla tła.

To jednak nie pomoże. Zobaczmy:

Obrazek nie jest przezroczysty pomimo podania w kolorze tła kanału alpha.

7. ImageSaveAlpha()

Dlaczego nie udało się nam uzyskać przezroczystości dla całego obrazka?
Ponieważ obrazek jako taki nie ma zapisanego w sobie kanału alpha, musimy to uczynić funkcją:
[code]imagesavealpha($image, true);[/code]
Nasz kod wyglądać więc będzie tak:
[code]
<?php
$width = 400;
$height = 300;
$image = imagecreatetruecolor($width, $height);
// stworzyliśmy pusty obrazek o szerokości 400px i wysokości 300px

$black = imagecolorallocatealpha($image, 0, 0, 0, 100);
// zdefiniowaliśmy kolor czarny dla tła, z kanałem alpha = 100

$red = imagecolorallocatealpha($image, 255, 0, 0, 64);
// zdefiniowaliśmy kolor czerwony i zapisaliśmy go do zmiennej $red, z kanałem alpha = 64

imagefill($image, 0, 0, $black);
// wypełniliśmy obszar 400x300px naszego obrazka kolorem pobranym ze zmiennej $black

imagefilledrectangle($image, 20, 20, 100, 120, $red);
// wypełniliśmy obszar od 20-100px w poziomie i 20-120px w pionie

header("Content-type: image/png");
// definiujemy nagłówek z mimetype

imagesavealpha($image, true);
// zapisujemy kanał ALPHA w obrazku

imagepng($image);
// generujemy obrazek PNG

imagedestroy($image);
// zwalniamy uchwyt do obrazka
?>
[/code]

Wynik:

Jak widać, tym razem obrazek wyświetli się nam w całości jako półprzezroczysty.
To tyle na początek, wiemy już mniej więcej jak działa bibioteka GD, w następnych artykułach poznamy następne jej funkcje i sposoby wykorzystania. W ramach ćwiczeń polecam poeksperymentowanie z udostępnionym tutaj kodem, zmieniając np. współrzędne i kolory, a następnie potestowanie wyników takich zmian.

[PHP] Funkcje anonimowe i callback

2015-05-27T17:10:00.003+02:00

Funkcje anonimowe i związane z nimi funkcje zwrotne (tzw. callback) to bardzo praktyczny mechanizm pozwalający na tworzenie bardzo ciekawych rozwiązań. Są wykorzystywane w wielu funkcjach wbudowanych w PHP, możemy też je wykorzystywać do budowania własnych tego typu rozwiązań. Trzeba bowiem wiedzieć, że jako argumenty do danej funkcji możemy w PHP przekazywać nie tylko zwykłe typy takie jak obiekty klas, zmienne, czy tablice, ale również i funkcje. Co więcej - funkcje podane jako argument mogą operować na danych zwróconych przez funkcję wywoływaną - nazywamy je wtedy funkcjami zwrotnymi, tzw. callbackami. Oczywiście nic nie stoi na przeszkodzie, aby wszystko działało o wiele bardziej skomplikowanie - funkcja zwrotna może np. odbierać wynik, przetwarzać go, a następnie ponownie przekazywać do funkcji bazowej. W tym artykule dowiemy się w jaki sposób w PHP można deklarować tego typu funkcje oraz zobaczymy na przykładzie w jaki praktyczny sposób można to rozwiązanie wykorzystać.

function()

Funkcja anonimowa może zostać zadeklarowana na dwa sposoby, na początek poznamy pierwszy sposób. Nie musi ona posiadać swojej nazwy, można ją jednak przypisać do zmiennej i używać zmiennej tak jakby była zwykłą funkcją.
Składnia taka moze powodować zdziwienie na pierwszy rzut oka, ale po zrozumieniu mechanizmu nie będzie w niej dla nas niczego dziwnego. Zdeklarujmy więc naszą pierwszą anonimową funkcję, przypisując ją do zmiennej:
[code]
<?php
$myFunction = function() {
echo 'This is myFunction.<br />';
};
?>
[/code]

Jak widać powyżej, funkcja taka nie posiada własnej nazwy, jest za to przypisywana do zmiennej $myFunction.
Co za tym idzie, wywołajmy teraz taki kod:
[code]$myFunction(); [/code]
Dziwna konstrukcja? Na pierwszy rzut oka być może tak, bo wygląda jak połączenie zmiennej z funkcją.
Tak też jest w istocie. Wywołanie powyższego nie spowoduje żadnego błędu i wyświetli nam wynik działania funkcji zadeklarowanej wyżej, czyli:
[code]This is myFunction.[/code]

Wyobraźmy sobie teraz, że mamy dodatkową funkcję przyjmującą jeden argument, np.:
[code]
function otherFunction($arg)
{
// ....ciało funkcji
}
[/code]
Co zostanie do niej przekazane, gdy wywołamy ją podając za argument zmienną $myFunction?
[code]otherFunction($myFunction);[/code]
Otóż - przekazana w argumencie zostanie nasza anonimowa funkcja.
Funkcję przekazaną możemy następnie wywołać w ciele funkcji do której została przekazana i zrobić z nią co tylko chcemy.

Funkcje anonimowe mogą naturalnie przyjmować argumenty, rozbudujmy zatem naszą anonimową funkcję o pobieranie dwóch liczbowych argumentów, następnie w wyniku wyświetlanie ich sumy:
[code]
$myFunction = function($a, $b) {
$c = $a + b;
echo 'This is myFunction:<br />' .
$a . '+' . $b . '=' . $c . '<br />';
};
[/code]

Wywołanie teraz:
[code]$myFunction(5, 2);[/code]

Spowoduje wywołanie funkcji i wyświetlenie nam:
[code]This is myFunction:
5+2=7[/code]

call_user_func()

Funkcje anonimowe (jak i zwykłe funkcje) wywoływać można za pomocą funkcji:
[code]call_user_func(nazwa_funkcji, argument1, argument2, ....);[/code]

Przykładowo:
[code]call_user_func($myFunction, 5, 2);[/code]
Wywoła nam funkcję anonimową przypisaną do zmiennej $myFunction z argumentami 5 i 2, co finalnie wyświetli nam wynik tak jak powyżej. W przykładzie tym podaliśmy zmienną zamiast nazwy funkcji, zwykłe wywołanie za pomocą podania jej nazwy jako stringu wyglądało by np. tak:
[code]
$html = '<b>this is html</b>';
$no_tags = call_user_func('strip_tags', $html);
echo $no_tags;
[/code]
Co w wyniku wywoła nam funkcję strip_tags() z argumentem $html.

call_user_func_array()

Argumenty do call_user_func można podawać również w formie tablicy, ale zrobimy to już funkcją:
[code]call_user_func_array(nazwa_funkcji, tablica_z_argumentami)[/code]
Przykład:
[code]
$str = 'color is black';
$a = 'black';
$b = 'white';
$replace = call_user_func_array('str_replace', array($a, $b, $str));
echo $replace;
[/code]
Wyświetli nam:
[code]color is white[/code]

call_user_func i klasy

Przeanalizowaliśmy prosty przykład z funkcjami, jak jednak za pomocą call_user_func() wywołać metody klasy.
Rozwiązań jest kilka, utwórzmy najpierw przykładową klasę:
[code]
class MyClass
{
public function myMethod()
{
echo 'This is myMethod from object. <br />';
}

public static function myStaticMethod()
{
echo 'This is myStaticMethod. <br />';
}
}
[/code]

Aby wywołać statyczną metodę myStaticMethod(), użyć musimy jednej z dwóch konstrukcji:
[code]call_user_func('MyClass', 'myStaticMethod');[/code]
lub bezpośrednio:
[code]call_user_func('MyClass::myStaticMethod');[/code]

W przypadku obiektu klasy i metody myMethod() zrobimy to tak:
[code]$obj = new MyClass;
call_user_func($obj, 'myMethod');[/code]

Możemy też odwoływać się np. do metody rodzica w klasie bazowej.
Utwórzmy dwie klasy, z czego druga dziedziczy po pierwszej:
[code]
class MyClassA
{
public static function who()
{
echo 'My class is: ' . __CLASS__ . '<br />';
}
}

class MyClassB extends MyClassA
{
public static function who()
{
echo 'My class is: ' . __CLASS__ . '<br />';
}
}
[/code]
Aby teraz z poziomu klasy B wywołać metodę klasy bazowej A użyjemy konstrukcji:
[code]call_user_func(array('MyClassB', 'parent::who'));[/code]
co wyświetli nam:
[code]My class is: MyClassA[/code]

CALLBACK

Wiemy już w jaki sposób wywoływać funkcje anonimowe (i zwykłe), więc zobaczmy teraz jak wykorzystać tą wiedzę do stworzenia callbacka. Na początek wymyślmy sobie jakąś funkcję, która będzie przyjmować funkcję anonimową jako callback i zwracać jej wynik swojego działania. Niech będzie to przykładowo funkcja obliczający pierwiastek kwadratowy z podanej jako argument liczby.
Funkcja obliczająca pierwiastek kwadratowy to:
[code]sqrt()[/code]
My jednak chcemy stworzyć bardziej rozbudowaną wersję, która nie tylko zwróci nam wynik, ale przekaże go do zdefiniowanej przez nas funkcji, którą podamy jako parametr. Na początek obmyślmy co taka funkcja zrobi z takim wynikiem - niech będzie, że po prostu go wyświetli.
Nasza funkcja callbackowa wyglądać więc będzie tak:
[code]
function myCallback($input)
{
echo 'My result is: ' . $input . '<br />';
}
[/code]
Jak widać jest to prosta funkcja - przyjmuje wynik w argumencie i wyświetla go za pomocą echo().
Argument $input zostanie jej przekazany przez naszą funkcję bazową, w której obliczymy pierwiastek, stwórzmy więc i tą funkcję:
[code]
function sqrtWithCallback($number, callable $callback)
{
$res = sqrt($number);
if(is_callable($callback))
{
call_user_func($callback, $res);
}
}
[/code]
Jak widzimy funkcja przyjmuje 2 argumenty:

$number - który pobiera liczbę, z której obliczać będziemy pierwiastek
$callback - funkcję zwrotną, której przekaże obliczony pierwiastek.

Co się dzieje dalej?
Pierwiastek jest obliczany i zapisywany w zmiennej $res.
Następnie mamy warunek, który wymaga omówienia:
Funkcja:
[code]is_callable(nazwa_funkcji)[/code]
sprawdza, czy podana jako argument nazwa funkcji jest w rzeczywistości funkcją, którą możemy wywołać za pomocą call_user_func(). Od strony technicznej - sprawdza, czy podana jako parametr funkcja jest typu callable/callback. Typy callback i callable oznaczają to samo, z tym że callable został wprowadzony dopiero w wersji 5.4 PHP.
Następnie, o ile funkcja istnieje jest ona wywoływana za pomocą call_user_func() z argumentem, w którym przekazywany jest jej wynik jaki obliczyliśmy.

Zobaczmy co się stanie po wywołaniu naszej funkcji:
[code]
$my_number = 16;
sqrtWithCallback($my_number, 'myCallback');
[/code]
Voila! Zostanie nam wyświetlone:
[code]My result is: 4[/code]

Funkcja zwrotna (callback) odebrała od funkcji bazowej wynik jej działania, następnie przetworzyła go po swojemu, wyświetlając nam wynik. Zmieńmy naszą funkcję obliczającą pierwiastek na trochę bardziej elegancką:
[code]
function sqrtWithCallback($number, callable $callback)
{
$res = sqrt($number);
if(!is_callable($callback) || !call_user_func($callback, $res)) {
return false;
}
return $res;
}
[/code]
Będzie działać tak samo, ale jednocześnie zwracac nam wynik w przypadku powodzenia, lub false w przypadku niemożliwości wywołania funkcji zwrotnej.

CALLBACK I KLASY

A jakim sposobem przesłać tutaj jako callback nie funkcję, a np. metodę klasy?
Bardzo podobnie jak w przypadku call_user_func(). Utwórzmy najpierw przykładową klasę:
[code]
class MyCallbacks {

public static function sqrtCallback($input)
{
echo 'My result is: ' . $input . '<br />';
}

public function sqrtCallbackObj($input)
{
echo 'My result is: ' . $input . '<br />';
}
}
[/code]
Następnie jako callback podajmy nazwę statycznej metody:
[code]
$my_number = 16;
$sqrt = sqrtWithCallback($my_number, 'MyCallbacks::sqrtCallback');
[/code]
Voila! Tym razem jako callback posłużyła nam metoda statyczna klasy MyCallbacks.

Analogicznie z utworzeniem obiektu klasy:
[code]
$obj = new MyCallbacks;
$sqrt = sqrtWithCallback($my_number, array($obj, 'sqrtCallbackObj'));
[/code]

CALLBACK I FUNKCJE ANONIMOWE

Dochodzimy więc do senda tego artykułu, a więc możliwości połączenia funkcji anonimowych z callbackiem.
W przykładzie powyżej podaliśmy jako callback zwykłą funkcję, zadeklarowaną normalnie, teraz zobaczmy jak podać tutaj funkcję anonimową. Można to zrobić na kilka sposobów. Na początek zadeklarujmy sobie taką anonimową funkcję:
[code]
$callback_func = function($input)
{
echo 'My result is: ' . $input . '<br />';
};
[/code]
Wywołajmy teraz funkcję bazową:
[code]
$my_number = 16;
sqrtWithCallback($my_number, $callback_func);
[/code]
Bingo! Ponownie otrzymalismy wynik z naszej funkcji zwrotnej, tym razem anonimowej, ale zadeklarowanej do zmiennej.

Prawdziwa jednak siła funkcji anonimowych tkwi w możliwości ich definiowania bezpośrednio w argumencie, popatrzmy:
[code]
$my_number = 16;
$sqrt = sqrtWithCallback($my_number, function($input) {
echo 'My result is: ' . $input . '<br />';
});
[/code]
Jak widzimy - deklarację naszej anonimowej funkcji podajemy bezpośrednio w argumencie funkcji ją przyjmującej.
Takiego też sposobu używać będziemy najczęściej, gdyż jest najbardziej ergonomiczny.
Warto to sobie przećwiczyć na własnych przykładach, gdyż zastosowań tego typu mechanizmu jest ogrom.

Więcej o funkcjach anonimowych i callbackach przeczytasz w manualu PHP:
http://php.net/manual/en/function.call-user-func.php
http://php.net/manual/en/function.call-user-func-array.php
http://php.net/manual/en/function.is-callable.php
http://php.net/manual/en/language.types.callable.php
http://php.net/manual/en/language.pseudo-types.php#language.types.callback

Na sam koniec jeszcze kod, który pokaże nam wszystkie sposoby działające po koleji:
[code]
<?php
// #1 - przypiszemy anonimową funkcje do zmennej $callback_func
$callback_func = function($input)
{
echo '#1: My result is: ' . $input . '<br />';
};

// #2 - normalna funkcja
function myCallback($input)
{
echo '#2: My result is: ' . $input . '<br />';
}

// #3 i #4 - metody w klasie
class MyCallbacks {

public function sqrtCallbackObj($input)
{
echo '#3: My result is: ' . $input . '<br />';
}

public static function sqrtCallback($input)
{
echo '#4: My result is: ' . $input . '<br />';
}
}

// nasza funkcja przekazująca wynik do callbacka
function sqrtWithCallback($number, callable $callback)
{
$res = sqrt($number);
if(!is_callable($callback) || !call_user_func($callback, $res)) {
return false;
}
return $res;
}

$my_number = 16;

// #1 wywołanie za pomocą zmiennej zawierającej funkcję:
$sqrt = sqrtWithCallback($my_number, $callback);

// #2 wywołanie za pomocą podania nazwy funkcji:
$sqrt = sqrtWithCallback($my_number, 'myCallback');

// #3 metoda obiektu klasy MyCallbacks:
$obj = new MyCallbacks;
$sqrt = sqrtWithCallback($my_number,array($obj, 'sqrtCallbackObj'));

// #4 metoda statyczna w klasie MyCallbacks:
$sqrt = sqrtWithCallback($my_number, 'MyCallbacks::sqrtCallback');

// #5 funkcja anonimowa z deklaracją w parametrze:
$sqrt = sqrtWithCallback($my_number, function($input) {
echo '#5: My result is: ' . $input . '<br />';
});
?>
[/code]

[APACHE] Konfiguracja HTTPS na localhoście - zabawa z OpenSSL

2015-05-26T23:22:00.001+02:00

W artykule tym nauczymy się jak na lokalnym serwerze stworzyć możliwości do obsługi protokołu https://. Pozwoli to nam na lokalne testowanie tych elementów naszej aplikacji, które w wersji produkcyjnej będą działać na połączeniu szyfrowanym. Do stworzenia sobie takiej funkcjonalności potrzebny będzie nam certyfikat SSL, którym konieczne będzie podpisanie naszego serwera. Certyfikaty takie kosztują i są wydawane dla konkretnej domeny przez uprawnione do tego organy, jak np. VeriSign. My oczywiście nie będziemy kupować żadnego certfikatu dla własnych lokalnych potrzeb - zamiast tego skorzystamy z darmowego pakietu OpenSSL i taki certyfikat wygenerujemy oraz podpiszemy sobie sami. Wiąże się to z pewną małą "niedogodnością" - mianowicie przeglądarki będą pluły nam informacją o tym, iż nasz certfikat jest niezaufany i z niepewnych źródeł ;) Wystarczy jednak to zignorować.

OpenSSL

No to zaczynamy. Pierwszą sprawą jest zaopatrzenie się w darmowy pakiet OpenSSL, który pobierzemy stąd: http://indy.fulgan.com/SSL/. Na Linuxach pakiet ten powinien być dostępny domyślnie, dla Windowsów musimy go pobrać, zróbmy więc to. Wchodzimy na w/w stronę, pobieramy najnowszą dostępną wersję odpowiednią dla naszego systemu (32/64 bity) i rozpakowujemy, np. do:
[code]C:\OpenSSL[/code]

To jedna sprawa - druga to włączenie modułu SSL w samym Apache'u (jest on domyślnie wyłaczony). Otwieramy do edycji plik konfiguracyjny Apache'a (jako administrator):
[code]/ścieżka/do/apache/conf/httpd.conf[/code]
i szukamy linijki:
[code]LoadModule ssl_module modules/mod_ssl.so[/code]
Jeśli jest ona poprzedzona komentarzem (#) to usuwamy go.
Zapiszmy plik i zrestartujmy Apache:
[code]httpd -k restart[/code]

Uwaga - jeśli nie posiadamy modułu "mod_ssl.so" to bedziemy musieli go do naszego Apacha doinstalować.

Klucz i certyfikat

Wróćmy do pobranego przez nas pakietu OpenSSL.
Czeka nas wygenerowanie nowego certyfikatu.
Służy do tego narzędzie openssl, a jakże ;)
Na początku stworzymy sobie folder na nasz certyfikat i klucz, np.
[code]C:\certSSL[/code]
Uruchomijmy zatem terminal/konsolę (UWAGA: koniecznie jako administrator), a następnie stwórzmy powyższy folder i wejdżmy do niego:
[code]mkdir C:\certSSL
cd C:\certSSL[/code]

Wpiszmy teraz w konsoli:
[code]openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout localhost.key -out localhost.cert[/code]

Rozpocznie się procedura generowania klucza.
Zostaniemy poproszeni o podanie danych takich jak kod naszego kraju, nazwa organizacji itd.
Wpiszmy tam jakieś podstawowe dane - zostaną one wpisane do certyfikatu.
Ważne jest jednak pole Common Name, określające adres strony dla jakiej wystawiamy certyfikat.
Jeśli wystawiamy dla naszego localhosta to wpiszmy tam:
[code]localhost[/code]

Jeśli wszystko poszło dobrze to powinniśmy w folderze C:\certSSL otrzymać 3 pliki:

.rnd
localhost.cert
localhost.key

Plik .rnd usuwamy.

Interesują nas 2 pozostałe pliki:

localhost.cert - czyli nasz certfikat
localhost.key - nasz wygenerowany klucz prywatny

Instalacja klucza i certyfikatu

Oba pliki kopiujemy do katalogu z konfiguracją Apache'a:
[code]/ścieżka/do/apache/conf/ssl[/code]
(katalog ssl tworzymy sami)

VHOST

Następnie będziemy musieli stworzyć nowego vhosta (więcej o tworzeniu vhostów napisałem w tym artykule). Wchodzimy zatem do pliku z konfiguracją vhostów, najczęściej jest to:
[code]/ścieżka/do/apache/conf/extra/httpd-vhosts.conf[/code]

i dodajemy nowego wirtualnego hosta, np:
[code]
<VirtualHost *:443>
ServerAdmin nasz@email.com
DocumentRoot "c:/www"
ServerName localhost
ServerAlias localhost
SSLEngine On
SSLCertificateFile conf/ssl/localhost.cert
SSLCertificateKeyFile conf/ssl/localhost.key
ErrorLog "logs/localhost-ssl-error.log"
CustomLog "logs/localhost-ssl-access.log" common
</VirtualHost>
[/code]

Jak widzimy w konfiguracji - połączeń po SSL nasłuchiwać będziemy na porcie 443
DocumentRoot pozostaje bez zmian, ale możemy tutaj podać oddzielny katalog na zawartość przesyłaną po https://.
To co najbardziej rzuca się w oczy, to:
[code]
SSLEngine On
SSLCertificateFile conf/ssl/localhost.cert
SSLCertificateKeyFile conf/ssl/localhost.key
[/code]
To właśnie tutaj uruchamiamy SSL dla tego vhosta oraz definiujemy ścieżki do certfyfikatu i klucza.

httpd.conf

Vhosta już mamy, ale to jeszcze nie wszystko, gdyż teraz w zależności od obecnej konfiguracji naszego Apache'a dalsza procedura moze być różna. Najlepiej wyszukajmy w pliku httpd.conf wszystkie wystąpienia słowa 'SSL' i przyjrzyjmy się jakie elementy odnośnie SSL są implementowane.
Kluczowym jest, abyśmy dodali w konfiguracji następujący wpis:
[code]
Listen 443
<IfModule ssl_module>
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
</IfModule>
[/code]

Pierwsza linijka nakazuje Apachowi nasłuchiwania na porcie 443 - bez niej nasz serwer nie przyjmie żadnego połaczenia po protokole HTTPS.
Kolejne parametry definiują rodzaj generowanego ziarna za pomocą liczb losowych.

https://

Jeśli wszystko poszło zgodnie z planem, to zrestartujmy serwer i spróbujmy dostać się do naszego localhosta za pomocą:

[code]https://localhost[/code]

Jeśli wszystko poszło jak należy, pominniśmy zostać na wstępie poinformowani o niepewnym pochodzeniu naszego certyfikatu, samo zaś połączenie po SSL powinno w tym momencie działać.

[APACHE] Autoryzacja za pomocą .htpasswd

2015-05-26T20:52:00.000+02:00

W Apache'u możemy ograniczyć dostęp do dowolnego katalogu za pomocą ustawienia wymogu autoryzacji. Jest to bardzo przydatna opcja, dzięki której możemy ograniczyć dostęp np. do testowych wersji projektów dla swoich klientów na zasadzie konieczności podania loginu oraz hasła użytkownika. Jest to prosta autoryzacja oparta na dwóch plikach, które w tym artykule przygotujemy - pliku .htpasswd, w którym będziemy przechowywać nasze hasła, oraz pliku .htaccess, który będzie z tego pliku korzystał w celu autoryzacji użytkownika. O ile plik .htaccess utworzymy w zwykłym notatniku, to już z plikiem .htpasswd będzie więcej zachodu, gdyż tego pliku nie jesteśmy w stanie przygotować "odręcznie". Wynika to z faktu, iż hasła przechowywane w tym pliku zapisywane są w formie szyfrowanej, zatem skorzystać będziemy musieli z jakiegoś narzędzia generującego nasze hasła w formie zaszyfrowanej.

.htpasswd

Pierwszym i podstawowym narzędziem służacym do generowania pliku z hasłami jest udostępnione w pakiecie z serwerem Apache konsolowe narzędzie o nazwie:
[code]htpasswd.exe[/code]
Innym sposobem na utworzenie pliku z hasłami jest skorzystanie z któregoś z dostępnych on-line generatorów.
Oto ich krótka lista:
http://www.htaccesstools.com/htpasswd-generator/
http://www.askapache.com/online-tools/htpasswd-generator/
http://aspirine.org/htpasswd_en.html
http://www.htpasswdgenerator.net/

Jak wygląda taki plik z hasłami?
Jest to zwykły plik tekstowy o postaci:
[code]login1:hasło1
login2:hasło2
login3:hasło3
...itd
[/code]

np.:
[code]
marek:$apr1$mFL7znbn$cQMJYoAf5gSXw0d2GAGNx.
anna:$apr1$ggN.pSSf$Dld5WOZkHlPP03g534R0X/
janusz:$apr1$GCpfbZ26$omnuEq040nxzQlYkYum.j.
...itd
[/code]

Użytkowników może być dowolna ilość, należy jednak pamiętać, aby każdy z nich określony był w oddzielnej linijce, na zasadzie:
[code]nazwa_użytkownika1:hasło_użytkownika1
nazwa_użytkownika2:hasło_użytkownika2
nazwa_użytkownika3:hasło_użytkownika3[/code]

Skorzystamy teraz z wbudowanego w Apache narzędzia, aby wygenerować nasz plik z hasłami.
Na początek mała uwaga - plik z hasłami przechowujemy w folderze niedostępnym z zewnątrz.
Stwórzmy sobie jakiś wydzielony folder, np.:
[code]C:\top_secret[/code]
w Windowsie

lub
[code]/home/użytkownik/top_secret[/code]
na Linuxie

i tam zapisujmy hasła.
Ważne jest jedynie, aby folder nie był dostępny z poziomu WWW.

Składnia poleceń narzędzia htpasswd.exe wygląda następująco:
[code]htpasswd.exe -parametr "/ŚCIEŻKA/DO/PLIKU/Z/HASŁAMI" nazwa_użytkownika[/code]

Utwórzmy więc np. użytkownika o nazwie "janusz" i dowolnym haśle.
Narzędzie pracuje w terminalu, wejdźmy więc do terminalu/konsoli i wpiszmy:
[code]htpasswd.exe -c "C:\top_secret\.htpasswd" janusz[/code]
Wciśnijmy ENTER, podajmy dwukrotnie hasło i to wszystko - plik został wygenerowany.

O ile wszystko wykonaliśmy poprawnie, plik C:\top_secret\.htpasswd powinień wyglądać jakoś tak:
[code]janusz:$apr1$R0L9yuuR$5yFjvKY5zzjcimetH3l.L.[/code]

Kolejnego użytkownika do tego pliku dodamy tak samo, ale pominiemy teraz parametr -c (skrót od CREATE). Dodajmy kolejnego użytkownika np. o nazwie "anna" i dowolnym haśle:
[code]htpasswd.exe "C:\top_secret\.htpasswd" anna[/code]

Nasz plik ma już dwóch użytkowników:
[code]
janusz:$apr1$zEw590ap$o9OvCKEbofz5v2SFE9SQJ0
anna:$apr1$AQA3qYnC$z32ZOrJNJWExBL6Y0BKIl0
[/code]

.htaccess

Teraz czas na zabawę z plikiem .htaccess.
Załóżmy, że na naszym serwerze posiadamy katalog:
[code]C:\WWW\top_secret_area[/code]
który chcemy zabezpieczyć hasłem.

Utwórzmy w nim plik .htaccess i wpiszmy do niego to co poniższe:
[code]
AuthType basic
AuthName "Top Secret Area"
AuthUserFile C:/top_secret/.htpasswd
Require valid-user
[/code]

Zapiszmy plik.
Teraz po koleji co tak naprawdę zrobiliśmy:

AuthType - określa sposób autoryzacji, może to być basic, lub digest, my wykorzystamy basic
AuthName - to nazwa wyświetlana po wejściu do chronionego zasobu, może być dowolna
AuthUserFile - podajemy pełną ścieżkę do pliku z hasłami
Require - wymieniamy po spacjach nazwy użytkowników, lub grup które mogą się logować, albo podajemy "valid-user", które oznacza, że logować może się każdy użytkownik opisany w pliku z hasłami. W przypadku podawania użytkownika:
Require user nazwa_użytkownika1 nazwa_użytkownika2 itd...
W przypadku grup:
Require group nazwa_grupy1 nazwa_grupy2 itd.....

Jeśli wszystko wykonaliśmy poprawnie, to po wejściu do naszego katalogu:
[code]http://localhost/top_secret_area[/code]
wyświetli nam się prośba o podanie loginu i hasła w celu uzyskania dostępu do zawartości.
Od tej chwili jedynie określeni przez nas użytkownicy mają dostęp do tego folderu.

Możemy też określać nazwy grup użytkowników, którzy mogą się logować:
W przypadku takim, tworzymy plik z grupami np.:
[code]C:\top_secret\groups[/code]

I wpisujemy w nim np.:
[code]tajna_grupa: janusz anna[/code]

Grup możemy dodać kilka, każdą w oddzielnej linijce, np.:
[code]tajna_grupa: janusz anna
inna_grupa: adam marek[/code]

Gdy mamy już plik z definicjami grup, dołączamy go do .htaccess i określamy kto może się logować tym razem podając grupę, a nie pojedyńczych użytkowników:
[code]
AuthType basic
AuthName "Top Secret Area"
AuthUserFile C:/top_secret/.htpasswd
AuthGroupFile C:/top_secret/groups
Require group tajna_grupa
[/code]

Uwaga: aby móc skorzystać z modułu autoryzacji w pliku .htaccess nasz katalog musi mieć ustawioną w konfiguracji httpd.conf dyrektywę AllowOverride na wartość "all" lub conajmniej na "AuthConfig".

[APACHE] Allow, Deny - konfiguracja dostępu do katalogów

2015-05-26T19:05:00.002+02:00

Podczas pracy z serwerem Apache bardzo często spotkamy się z regułami Allow i Deny, które odpowiadają za ustawianie reguł dostępu do danego katalogu z zewnątrz. Reguły te można narzucać globalnie za pomocą głównego pliku konfiguracyjnego Apache'a, można także je nadpisywać w plikach .htaccess o ile na to zezwolimy. Reguły dostępu mają ściśle określoną składnię i warto się z nią zapoznać, aby móc wykorzystywać to w praktyce. Nie jest to trudne i ogranicza się w zasadzie do zrozumienia kilku podstawowych zasad. W tym krótkim artykule postaram się wyjaśnić na czym polega konfiguracja takich reguł, a także kiedy i jak należy je stosować.

Na wstępie musimy mieć świadomość, iż wszystko to co Apache udostępnia "na zewnątrz" może zostać skonfigurowane i określone wg zadanych mu reguł. Poprawna konfiguracja ma kluczowe znaczenie dla bezpieczństwa naszego serwera, a zasada "im mniej udostępniamy w świat, tym lepiej" ma tutaj bardzo duże znaczenie. Złotą zasadą udostępniania aplikacji na zewnątrz jest wydzielenie odpowiedniej struktury logicznej naszego projektu i podzielenie jej na dwie sekcje: sekcję, która MUSI zostać udostępniona na zewnątrz - szablon strony, pliki CSS, skrypty .js, czy dołączane grafiki oraz na sekcję z właściwym kodem naszej aplikacji, do której po stronie klienta nie powinno być już dostępu. Warto bowiem zauważyć, że to co udostępnione jest klientowi != temu do czego dostęp ma serwer. Ograniczając udostępniane na zewnątrz zasoby, nie ograniczamy zatem naszej aplikacji, gdyż po stronie serwera ma ona wciąż dostęp do całości kodu ukrytego przed użytkownikiem. Przykładem moze być tutaj popularny framework Symfony, który na zewnątrz udostępnia jedynie folder "web/", natomiast cała logika aplikacji znajduje się w folderach powyżej, nie udostępnionych przez WWW.

ORDER, DENY, ALLOW

To pierwsza kluczowa sprawa jaką należy zrozumieć.
Popatrzmy na przykładową konfigurację dostępu do danego katalogu:

[code]
Order deny,allow
Deny from all
Allow from 127.0.0.1
[/code]

W pierwszej linijce mamy określoną kolejność przetwarzania reguły:
[code]Order deny,allow[/code]
gdzie:

deny - oznacza dostęp zabroniony
allow - oznacza przyznanie dostępu

Podana jest tutaj kolejność "deny,allow" - oznacza to, iż najpierw przetwarzane są reguły zabraniające dostępu, dopiero następnie reguły zezwalające na dostęp.
Aby to zrozumieć popatrzy dalej - w drugiej linijce:
[code]Deny from all[/code]
zabraniamy dostępu dla wszystkich,

aby po chwili w linijce trzeciej:
[code]Allow from 127.0.0.1[/code]
zezwolić na dostęp jedynie z adresu 127.0.0.1, czyli tylko dla nas samych.
Określona wcześniej kolejność - deny, allow powoduje więc, że reguła "allow" niejako nadpisuje regułę "deny.

Aby to lepiej zrozumieć, zamieńmy teraz kolejność przetwarzania reguł:
[code]
Order allow,deny
Deny from all
Allow from 127.0.0.1
[/code]

Powyzsza reguła spowoduje, iż dostęp do katalogu zostanie zabroniony DLA WSZYSTKICH, nawet pomimo faktu, że najpierw podane mamy:
[code]Deny from all[/code]
a po nim przecież:
[code]Allow from 127.0.0.1[/code]

Nie ma więc tutaj znaczenia w jakiej kolejności podajemy reguły, znaczenie ma jedynie słowo kluczowe "Order" i ustawiona za pomocą niego kolejność przetwarzania. W tym drugim przypadku, czyli:
[code]
Order allow,deny
Deny from all
Allow from 127.0.0.1
[/code]
zadziała to więc wg następującej kolejności:

zezwalamy na dostęp dla 127.0.0.1
zabraniamy dostępu dla każdego (a więc tym samym odbieramy go także dla adresu 127.0.0.1)

Ogólnia składnia prezentuje się więc następująco:

[code]Allow from adres/host[/code]
dla ustawienia dostępu

oraz:
[code]Deny from adres/host[/code]
dla zabronienia dostępu

...gdzie w miejsce adres/host możemy podać:

all - obowiązuje dla WSZYSTKICH adresów i hostów
adres IP, np. 127.0.0.1
wybrane adresy IP, np. 192.168.0.1 192.168.0.2 192.168.0.3 (oddzielamy je spacją)
zakres adresów IP, np. 192.168.0.0/24 (jak korzystać z masek adresów opisane jest np. tutaj: http://www.dslreports.com/faq/15216)
nazwę hosta lub hostów, np. localhost host2 host3... (tu trzeba zaznaczyć, że podajemy końcową nazwę hosta, np. podanie 'localhost' zezwoli też na dostęp dla 'abc.localhost')
zmienną, env=wartość zmiennej... (o tym poniżej)

Zmienną ustawić możemy w następujący sposób:
[code]SetEnv NAZWA_ZMIENNEJ "wartość zmiennej"[/code]

np.
[code]SetEnv myServerName %{SERVER_NAME}[/code]
ustawi zmiennej myServerName wartość odpowiadającą nazwie naszego serwera

Jak używać zmiennych w regułach dostępu?
Spójrzmy na przykład:
[code]
SetEnvIf User-Agent ^TopSecretBrowser set_access_to_me
Order deny,allow
Deny from all
Allow from set_access_to_me
[/code]
Powyższa reguła sprawdza, czy przeglądarka identyfikuje się ciągiem zaczynającym się od "TopSecretBrowser" - jeśli tak to ustawia zmienną "set_access_to_me".
Następnie:
[code]Allow from set_access_to_me[/code]
powoduje, iż w przypadku ustawionej zmiennej "set_access_to_me" zostaje nam przyznany dostęp.

Mały tip: do ustawionych w Apache'u zmiennych możemy odwołać się z poziomu PHP, za pomocą:
[code]<?php $zmienna = getenv(NAZWA_ZMIENNEJ_APACHE); ?>[/code]

<Directory "/path/to">

W pliku httpd.conf możemy ustawić oddzielne reguły dla zadanych katalogów.
Robimy to za pomocą dyrektywy "Directory", np.:
[code]
<Directory "/ścieżka/do/folderu">
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Directory>
[/code]
gdzie /ścieżka/do/folderu to pełna ścieżka do katalogu, np.:
[code]/var/www/katalog[/code]
na Linuxach

lub:
[code]C:/WWW/katalog[/code]
na Windowsach

Warto pamiętać, iż dana reguła dostępu działać będzie również na podkatalogi w katalogu, do którego ustawiamy dostęp, o ile oczywiście nie nadpiszemy tej reguły w danym podkatalogu.

.htaccess

Reguły takie umieszczać można także w plikach .htaccess
W przypadku takim - reguła obowiązywać będzie dla katalogu, w którym plik .htaccess z regułami się znajduje oraz dla jego podkatalogów (do momentu jej nadpisania przez inny .htaccess).
Plik .htaccess nadpisze wtedy ustawienia tutaj, zamieniając je na swoje własne.
Możliwość korzystania z pliku .htaccess w danym katalogu włączyć lub wyłączyć możemy za pomocą dyrektywy:
[code]AllowOverride[/code]
która może przyjąć kilka możliwych wartości:

All - zezwala na nadpisywanie wszystkich opcji za pomocą .htaccess
None - nie pozwala na nadpisywanie żadnych opcji
FileInfo - pozwala na korzystanie w .htaccess z opcji dotyczących kontroli dokumentu, nagłówków, przekierowań, modułu rewrite itp. opcji
AuthConfig - pozwala na korzystanie w .htaccess z opcji dotyczących autoryzacji, jak AuthName, AuthType itp.
Limit - pozwala na ograniczanie dostępu w .htaccess, za pomocą poznanych właśnie Allow i Deny

Możemy podać kilka wartości, oddzielonych spacjami, np.:
[code]AllowOverride FileInfo Limit[/code]

Przykładowo, poniższa konfiguracja zabroni nam na zmianę ustawień za pomocą pliku .htaccces w katalogu "C:/WWW/katalog"
[code]
<Directory "C:/WWW/katalog">
AllowOverride none
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Directory>
[/code]

a poniższa zezwoli na takie działania:
[code]
<Directory "C:/WWW/katalog">
AllowOverride all
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Directory>
[/code]

REQUIRE ALL

W pliku konfiguracyjnym możemy się też spotkać z następującą dyrektywą:
[code]Require all granted[/code]
która działa tak samo jak:
[code]Allow from all[/code]

oraz:
[code]Require all denied[/code]
która działa tak samo jak:
[code]Deny from all[/code][/code]

Zapis:
[code]
<Directory "C:/WWW/katalog">
Require all granted
</Directory>
[/code]

będzie równoważny z:
[code]
<Directory "C:/WWW/katalog">
Allow from all
</Directory>
[/code]

Analogicznie sprawa wygląda z dyrektywą Deny.
Zapis:
[code]
<Directory "C:/WWW/katalog">
Require all denied
</Directory>
[/code]

będzie równoważny z:
[code]
<Directory "C:/WWW/katalog">
Deny from all
</Directory>
[/code]

W przypadku ustawieniu braku dostępu do katalogu, serwer zwraca do klienta nagłówek z kodem 403 oraz domyślnie wyświetla użytkownikowi komunikat:

Forbidden

You don't have permission to access / on this server.

No i to tyle odnośnie podstawowej kontroli dostępu do katalogów w serwerach Apache. W następnych artykułach dowiemy się trochę więcej, a także nauczymy się korzystać z autoryzacji przy dostępie do katalogów.

[APACHE] Jak stworzyć i skonfigurować VirtualHosta?

2015-05-26T16:52:00.004+02:00

Vhosty do bardzo wygodny mechanizm do pracy z Apachem. Pomijając już nawet zastosowania typowo produkcyjne, są świetnym ułatwieniem podczas tworzenia środowisk testowych dla swoich webowych aplikacji. Zdejmują nam ograniczenie jednego katalogu głównego dla aplikacji pozwalając na tworzenie wielu różnych środowisk w obrębie jednego katalogu głównego. Przydają się też podczas testowania przekierowań modułu rewrite, a także podczas pracy z SSL, gdzie możemy wydzielić sobie oddzielną poddomenę na szyfrowaną zawartość. W tym krótkim przewodniku opiszę procedurę tworzenia takiego vhosta w oparciu o pliki konfiguracyjne Apache'a na Windowsie. Na Linuxach konfiguracja jest analogiczna, ale różni się kilkoma formalnymi zabiegami.

Czym jest wirtualny host? Vhost jest aliasem nakładanym na dany katalog na serwerze, do którego to katalogu przypisujemy odpowiednią subdomenę, przy czym katalog taki staje się Document Rootem dla tworzonej subdomeny.
Przykładowo, dysponując lokalnym serwererem "localhost" z ustawionym Document Root na dajmy na to przykładowo:
[code]C:\WWW\[/code]

możemy stworzyć w nim kilka podfolderów, np.:
[code]
C:\WWW\subdomena1
C:\WWW\subdomena2
... itd.
[/code]

a następnie utworzyć vhosty kierujące na te katalogi:
[code]
http://localhost >>> C:\WWW\
http://subdomena1.localhost >>> C:\WWW\subdomena1\
http://subdomena2.localhost >>> C:\WWW\subdomena2\
... itd.
[/code]

gdzie oczywiście vhostami są tutaj:
[code]
subdomena1.localhost
i
subdomena2.localhost
[/code]

Czego będziemy potrzebować, poza oczywiście zainstalowanym Apachem?

dostępu do katalogu systemowego, a więc uprawnień administratora
dowolnego edytora tekstowego, może być zwykły systemowy Notepad (od siebie polecam Notepada++ do wszelakich "małych" operacji na plikach tekstowych)

1) hosts - konfiguracja DNS

Pierwsze co musimy zrobić do dostać się do pliku, który robi w systemie za pierwszy odpytywany DNS.
W Windowsie plik ten znajdziemy tutaj:
[code]C:\Windows\System32\drivers\etc\hosts[/code]
W Linuxach:
[code]/etc/hosts[/code]

Tutaj mała uwaga: musimy otworzyć go do edycji w trybie administracyjnym, inaczej nie będziemy mieć możliwości zapisania w nim zmian. Aby tego dokonać (w systemach windowsowych), klikamy PPM na edytorze tekstowym jakiego chcemy użyć i wybieramy opcję "Uruchom jako administrator".
W unixowych systemach dokonujemy tego przez polecenie "sudo".

Otwieramy plik do edycji i naszym oczom pokaże się coś mniej więcej takiego:
[code]
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host

# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost

127.0.0.1 localhost
[/code]

Budowa pliku jest bardzo prosta:
W oddzielnych linijkach podajemy przypisania danych hostów do adresów IP.

Zapis:
[code]127.0.0.1 localhost[/code]
mówi systemowi, że hosta localhost ma on w pierwszej kolejności szukać pod adresem 127.0.0.1, który jest lokalnym adresem naszej maszyny, tzw. loopback-iem. Adres 127.0.0.1 zawsze prowadzi do nas samych. W tym przypadku zatem zarazem prowadzi do naszego lokalnego serwera jeśli mamy zainstalowanego Apacha. Kolejne adresy podajemy tutaj w oddzielnych linijkach, na zasadzie:
[code]ADRES_IP host[/code]

Dodajmy więc kilka subdomen:
[code]
127.0.0.1 subdomena1.localhost
127.0.0.1 subdomena2.localhost
[/code]

Mała uwaga: jeśli chcemy wejść na localhosta z "www" na początku, to również i to musimy uwzględnić w pliku hosts.
Nasz plik hosts może więc przyjąć taką postać:
[code]
....
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host

# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost

127.0.0.1 localhost
127.0.0.1 subdomena1.localhost
127.0.0.1 subdomena2.localhost
127.0.0.1 www.localhost
127.0.0.1 www.subdomena1.localhost
127.0.0.1 www.subdomena2.localhost
[/code]

Zapisujemy plik i kierujemy się w stronę Apacha.
Najpierw oczywiście utwórzmy odpowiednie foldery, do których będziemy kierowali vhosty, np.:
[code]
C:\WWW\subdomena1
C:\WWW\subdomena2
[/code]
Jest to bardzo ważne, aby katalogi istniały, gdyż w przeciwnym wypadku Apache odmówi nam dalszej współpracy, gdy nie znajdzie katalogu na jaki będzie miał kierować ruch.

2) httpd.conf - konfiguracja Apache'a

Teraz możliwe są dwie opcje, zależnie od konfiguracji naszego Apache'a. Możemy mieć właczoną, lub wyłaczoną obsługę vhostów. Domyślnie plik z vhostami nie jest dołączany do konfiguracji Apache'a - jeśli tak jest w naszym przypadku, zmienimy to:

Otwieramy do edycji plik konfiguracyjny Apache'a (ponownie na prawach administracyjnych!):
[code]ścieżka/do/apache2/conf/httpd.conf[/code]

i szukamy linii wyglądającej tak:
[code]Include conf/extra/httpd-vhosts.conf[/code]

Linijka ta odpowiada za dołączenie do konfiguracji pliku z definicjami vhostów.
Jeśli przed słowem "Include" znajduje się znak komentarza (#) to usuwamy go i zapisujemy plik.

3) httpd-vhosts.conf - konfiguracja wirtualnych hostów

Otwieramy teraz plik (ponownie z administracyjnymi uprawnieniami):
[code]ścieżka/do/apache2/conf/extra/httpd-vhosts.conf[/code]

który wyglądać będzie mniej więcej tak:
[code]
# Virtual Hosts
#
# Required modules: mod_log_config

# If you want to maintain multiple domains/hostnames on your
# machine you can setup VirtualHost containers for them. Most configurations
# use only name-based virtual hosts so the server doesn't need to worry about
# IP addresses. This is indicated by the asterisks in the directives below.
#
# Please see the documentation at
# <URL:http://httpd.apache.org/docs/2.4/vhosts/>
# for further details before you try to setup virtual hosts.
#
# You may use the command line option '-S' to verify your virtual host
# configuration.

#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for all requests that do not
# match a ServerName or ServerAlias in any <VirtualHost> block.
#
<VirtualHost *:80>
ServerAdmin webmaster@dummy-host.example.com
DocumentRoot "c:/www"
ServerName localhost
ServerAlias localhost
ErrorLog "logs/localhost-error.log"
CustomLog "logs/localhost-access.log" common
</VirtualHost>
[/code]

Każdy blok <VirtualHost>...</VirtualHost> to definicja oddzielnego vhosta.
Dodajmy więc nasze vhosty, które zdefiniowaliśmy w pliku "hosts" jako:
[code]
subdomena1.localhost
subdomena2.localhost
[/code]

Zrobimy to, dodając kolejny blok z definicją:
[code]
<VirtualHost *:80>
ServerAdmin nasz@email.com
DocumentRoot "c:/www/subdomena1"
ServerName subdomena1.localhost
ServerAlias subdomena1.localhost
ErrorLog "logs/subdomena1-error.log"
CustomLog "logs/subdomena1-access.log" common
</VirtualHost>
[/code]

I analogiczny blok dla subdomeny2:
[code]
<VirtualHost *:80>
ServerAdmin nasz@email.com
DocumentRoot "c:/www/subdomena2"
ServerName subdomena2.localhost
ServerAlias subdomena2.localhost
ErrorLog "logs/subdomena2-error.log"
CustomLog "logs/subdomena2-access.log" common
</VirtualHost>
[/code]

Każda taka konfiguracja vhosta jak widzimy składa się z kilku podstawowych elementów:

[code]<VirtualHost *:80>[/code]
Definiuje na jakim porcie dla tego hosta ma nasłuchiwać serwer, domyślnie jest to port HTTP 80, czasami 8080.

[code]ServerAdmin nasz@email.com[/code]
Określna adres email admina serwera, możemy tutaj podać cokolwiek

[code]DocumentRoot "c:/www/subdomena2"[/code]
Wskazuje pełną ścieżkę do katalogu głównego na jaki prowadzić będzie adres hosta

[code]ServerName subdomena2.localhost[/code]
Definiuje nazwę hosta, musi odpowiadać wpisowi w pliku "hosts"

[code]ServerAlias subdomena2.localhost[/code]
Definiuje alias dla hosta, musi odpowiadać wpisowi w pliku "hosts"

[code]ErrorLog "logs/subdomena2-error.log"[/code]
Ustawia plik z logami błędów na "logs/subdomena2-error.log"

[code]CustomLog "logs/subdomena2-access.log" common[/code]
Ustawia plik z logami dostępu do hosta na "logs/subdomena2-access.log"

Tutaj mała uwaga - jeśli chcemy korzystać również z przedrostka "www." przy podawaniu nazwy subdomeny, powinniśmy zastosować wildcarda (*) w definicji ServerAlias, tj.:
[code]ServerAlias *.subdomena1.localhost[/code]

Nasz plik finalnie wyglądać będzie więc mniej więcej tak:
[code]
# Virtual Hosts
#
# Required modules: mod_log_config

# If you want to maintain multiple domains/hostnames on your
# machine you can setup VirtualHost containers for them. Most configurations
# use only name-based virtual hosts so the server doesn't need to worry about
# IP addresses. This is indicated by the asterisks in the directives below.
#
# Please see the documentation at
# <URL:http://httpd.apache.org/docs/2.4/vhosts/>
# for further details before you try to setup virtual hosts.
#
# You may use the command line option '-S' to verify your virtual host
# configuration.

#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for all requests that do not
# match a ServerName or ServerAlias in any <VirtualHost> block.
#
<VirtualHost *:80>
ServerAdmin webmaster@dummy-host.example.com
DocumentRoot "c:/www"
ServerName localhost
ServerAlias *.localhost
ErrorLog "logs/localhost-error.log"
CustomLog "logs/localhost-access.log" common
</VirtualHost>

<VirtualHost *:80>
ServerAdmin nasz@email.com
DocumentRoot "c:/www/subdomena1"
ServerName subdomena1.localhost
ServerAlias *.subdomena1.localhost
ErrorLog "logs/subdomena1-error.log"
CustomLog "logs/subdomena1-access.log" common
</VirtualHost>

I analogiczny blok dla subdomeny2:
<VirtualHost *:80>
ServerAdmin nasz@email.com
DocumentRoot "c:/www/subdomena2"
ServerName subdomena2.localhost
ServerAlias *.subdomena2.localhost
ErrorLog "logs/subdomena2-error.log"
CustomLog "logs/subdomena2-access.log" common
</VirtualHost>
[/code]

Zapisujemy plik.
Poprawność konfiguracji vhostów możemy zweryfikować w konsoli, wpisując:
[code]ścieżka/do/apache2/bin/httpd -S[/code]

Jeśli wszystko jest OK, to restartujemy Apache'a, możemy to zrobić poleceniem:
[code]ścieżka/do/apache2/bin/httpd -k restart[/code]

To wszystko.
Od tej chwili możemy korzystać z naszych wirtualnych hostów pod adresami:
[code]
http://subdomena1.localhost
http://subdomena2.localhost
[/code]

Polecam naprawdę używanie vhostów do pracy nad różnymi aplikacjami.
Jest to bardzo wygodne i efektywne rozwiązanie separujące nam aplikacje, nad którymi pracujemy do oddzielnych od siebie domen. Wymaga to jak widać odrobiny czasu na konfigurację, ale zaręczam, że naprawdę warto pracować w taki właśnie sposób, zamiast robić to na zasadzie:
[code]
http://localhost/aplikacja1
http://localhost/aplikacja2
...itd
[/code]

[APACHE][mod_rewrite] Reguły, warunki i atrybuty - tworzymy pierwsze praktyczne przekierowania

2015-05-25T19:33:00.001+02:00

W poprzedniej części, czyli we wstępie określiliśmy sobie czym jest mod_rewrite, na co mniej więcej pozwala i jak wygląda przykładowa reguła przepisywania adresu. W tym odcinku nauczymy się tworzyć bardziej zaawansowane reguły, które pozwolą już na w pełni określone działanie naszych adresów. Przy okazji opiszę tutaj kilka standardowych problemów wraz z rozwiązaniami jak sobie z nimi radzić, gdyż mod_rewrite do poprawnego działania wymaga kilku "tricków". Nauczymy się też testowania stworzonych reguł oraz przeanalizujemy atrybuty reguł oraz dostępne w mod_rewrite zmienne.

Na początek małe przepomnienie - reguły określone w pliku .htaccess działają na folder, w którym plik ten się znajduje oraz na wszystkie jego podfoldery (o ile w danym podfolderze nie umieścimy kolejnego .htaccess nadpisującego reguły z pliku nadrzędnego). Na potrzeby tego poradnika nasz .htaccess umieszczamy w katalogu głównym naszego serwera. Przy okazji mały tip: nazwę pliku .htaccess można zmienić na inną dowolną, np. na "config" - określa się to w konfiguracji Apache'a, radzę jednak pozostać przy domyślnej nazwie, żeby trzymać się standardów.

Środowisko testowe

Na potrzeby nauki powinniśmy przygotować sobie jakieś środowisko testowe.
Moją propozycją jest utworzenie wirtualnego hosta na naszym lokalnym serwerze, tak abyśmy do testowanej strony mieli dostęp z poziomu subdomeny:

[code]rewrite.localhost[/code]

Głównym katalogiem (DocumentRoot) dla vhosta niech będzie np.
[code]/NASZ_GŁÓWNY_KATALOG_Z_WWW/rewrite/[/code]
i to na niego przekierujemy subdomenę 'rewrite'.
Jak stworzyć vhosta opisałem w tym artykule.

Dlaczego takie rozwiązanie, a nie np. 'localhost/rewrite'?
Ponieważ w momencie, gdy adres główny będzie miał postać typu 'serwer/katalog' to stworzy nam to nadprogramowy ciąg (katalog/) w adresie, co za tym idzie nasze reguły będą musiały go uwzględniać. Można też oczywiście wszystko wrzucić bezpośrednio na localhost, wygodniej jednak jest tworzyć sobie oddzielne subdomeny (vhosty) do danych eksperymentów. No dobrze, jeśli mamy już vhosta, lub jeśli wybraliśmy katalog główny localhosta, to przystępujemy do pracy - utwórzmy w głównym katalogu plik .htaccess, na nim będziemy pracować.

Tutaj jeszcze jedna wskazówka odnośnie testowania regułek - bardzo przyda się nam strona:
http://htaccess.madewithlove.be/
która zawiera tester online dla takich reguł, wypluwając nam wynik przekierowania w czasie rzeczywistym. Bardzo gorąco polecam do testowania zasad i reguł, gdyż jest to niesamowicie przydatne narzędzie.

Przygotujmy sobie też w głównym katalogu plik 'index.php', który będzie pokazywał nam na bieżąco parametry pobierane z przepisanego URL-a:
[code]<?php
// index.php
foreach($_GET as $k => $v)
{
echo $k . ' = ' . $v . '<br />';
}
?>[/code]

Zmienne

Na początek warto znać podstawowe zmienne, które udostępniane są nam do wykorzystania w pliku .htaccess:
Zakładając, że wywołujemy w adresie następujący URL, a właściwie to URI, ale na potrzeby poradnika używajmy bardziej przyjemnej nazwy URL:
[code]http://rewrite.localhost/kategorie/21[/code]

%{REQUEST_FILENAME} - ścieżka i nazwa do wywoływanego w adresie pliku/katalogu, tutaj: kategorie/21
%{REQUEST_URI} - pełny adres zapytania z jakiego nastąpiło wywołanie, tutaj: rewrite.localhost/kategorie/21
%{REQUEST_TIME} - obecny czas wywołania adresu
%{HTTP_HOST} - adres hosta do jakiego nastąpiło w adresie wywołanie, tutaj: rewrite.localhost
%{REQUEST_METHOD} - rodzaj wywołania (GET/POST/PUT...itp)
%{HTTP_REFERER} - adres, z którego nastąpiło wywołanie adresu
%{QUERY_STRING} - wartość parametrów z adresu, np. wywołując 'http://localhost/kategorie/lista.html?sort=desc' zawierać będzie 'sort=desc'
%{DOCUMENT_ROOT} - katalog główny (pełna ścieżka)
%{AUTH_TYPE} - rodzaj autoryzacji dla katalogu (Digest/Basic...)
%{THE_REQUEST} - pełna treść wywołania, tutaj: GET /kategorie/21/ HTTP/1.1

To tylko kilka główniejszych zmiennych, które pozwolą na standardową pracę z mod_rewrite.
Pełna lista zmiennych, wraz z opisami (a jest ich dużo) znajduje się pod adresem:
http://www.askapache.com/htaccess/mod_rewrite-variables-cheatsheet.html, natomiast lista najczęściej używanych zmiennych - pod koniec artykułu.

Przypomnijmy sobie przekierowanie jakie utworzyliśmy we wstępie:
[code]
# .htaccess
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^/.]+)/?$ index.php?action=$1
[/code]

Tworzyło ono przekierowanie z:
[code]http://nazwa_hosta/AKCJA[/code]
do
[code]index.php?action=AKCJA[/code]
uprzednio sprawdzając, czy w katalogu nie istnieje plik, lub folder o nazwie AKCJA.

Pierwszy problem - końcowy slash
I w tym momencie napotykamy na pierwszy z problemów do rozwiązania, mianowicie na fakt występowania końcowego slasha.Na czym polega nasz problem?
Na tym - adres nasz może wyglądać tak:
[code]http://rewrite.localhost/kategorie[/code]
ale moze i tak:
[code]http://rewrite.localhost/kategorie/[/code]

/dla celów testowych, będziemy tutaj wykorzystywać umownie nazwę naszego vhosta - rewrite.localhost/

Akurat w naszej regułce obie formy wykonają poprawne przekierowanie, ale żeby ustandaryzować sobie formę adresu, na jakim będziemy dalej operować powinniśmy sprawić, aby:
- albo wszystkie adresy kończyły się slashem
- albo żeby żaden z adresów nie kończył się slashem

Rozwiązanie takie jest ponadto dobrą praktyką jeśli chodzi o roboty wyszukiwarek - w przypadku linku z końcowym slashem i linku bez slasha mamy DWA różne linki, a więc zdublowaną zawartość, co nie jest mile widziane przez wyszukiwarki.

Dodamy slasha na końcu do każdego adresu, zrobimy to warunkiem:
[code]RewriteCond %{REQUEST_URI} !(.*)/$[/code]
Powyższy warunek sprawdza, czy adres URL (REQUEST_URI) nie równa się wyrażeniu ze slashem na końcu (negacja - !)

jeśli nie, to tworzymy przekierowanie dla takiego adresu, za pomocą:
[code]RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1/ [L,R=302][/code]
Powyższa reguła przepisuje każdy adres na taki sam, ale ze slashem na końcu.
Następnie mamy tutaj podane dwa argumenty objęte w nawiasy kwadratowe.
Argumenty te wymagają wyjaśnienia.

Argumenty reguł

Tóż po wyrażeniu obsługującym regułę przekierowania w nawiasach kwadratowych [ ] możemy podać listę dodatkowych argumentów/parametrów/znaczników/flag - spotkamy się z różnymi nazwami - my przyjmijmy określenie "argumenty".
Argumenty takie mówią serwerowi co dodatkowo ma zrobić po wykonaniu reguły je poprzedzającej. Argument możemy podać jeden, możemy też kilka - w przypadku większej ich ilości podajemy je wszystkie w obrębie jednego nawiasu, oddzielając je przecinkiem. Lista możliwych argumentow jest długa i zostanie opisana na końcu artykułu, na chwilę obecną przedstawię jedynie te najczęściej wykorzystywane:

[L] - skrót od "Last". Określa, iż reguła zawarta w linijce z tym argumentem jest ostatnią regułą przekierowania.
Na czym to polega? Otóż mod-rewrite przelatuje po koleji po wszystkich pasujących regułach, aż do samego końca.
Działanie takie jest zapętlone, aż do wykonania ostatniej pasującej reguły. Parametr [L] mówi serwerowi, że obecna regułka jest ostatnią i że w tym miejscu, jeśli nastąpi jej wykonanie nakazuje zignorowanie następujących po niej reguł. Wykorzystywane to jest głównie przy określaniu "sztywnych" przekierowań.

[R=] - skrót od "Redirect", czyli przekierowanie. Po znaku "=" przyjmuje kod przekierowania, a więc kod statusu z grup 300 i 400.
Przykładowo: [R=301] określa przekierowanie trwałe (301 Moved Permamently), natomiast [R=302] nakazuje przekierowanie tymczasowe (302 Moved Temporaly).
W celach testowych powinniśmy zamiast przekierowań 301 używać tych o statusie 302, czyli czasowych. Dlaczego? Dlatego, iż np. Firefox zapamiętuje permamentne przekierowania w cache'u, co może czasem utrudnić testowanie naszych regułek. W ostatecznej wersji natomiast powinniśmy używać 301.

[NC] - skrót od "No case". Sprawia, że ignorowana jest wielkość liter podczas dopasowania i tak np. reguła dla "index.php" w adresie bedze obowiązywać również dla "InDeX.pHp".

[N] - skrót od "Next". Powoduje rozpoczęcie przepisywania reguł od początku, z tym, że każde kolejne dopasowania wykonywane są dla już obecnie przepisanego URL-a, nie dla tego bazowego

[C] - skrót od "Chain", czyli łańcuch. Powoduje zawarcie kilku reguł w jeden łańcuch (grupę). Jeśli nie wystąpi żadna z reguł w takim łańcuchu, to wykonywana jest reguła po nich występująca.

[T=] - skrót od "Mime Type". Pozwala na ustawienie własnego typu MIME. Np. wykonanie [T=image/png] spowoduje wywołanie przepisanego URL-a z typem "image/png".

Argumentów tych jest o wiele więcej. Opisałem w skrócie te najczęściej używane.
Pełna lista argumentów znajduje się na samym dole artykułu.

Istnieją także 2 argumenty dla dyrektywy RewriteCond:

[NC] - jak wyżej, ignorujący wielkość znaków
[OR] - domyślnie warunki są łączone za pomocą operatora logicznego AND, tj. muszą być spełnione wszystkie, aby wykonać regułę. Argument [OR] jak sama nazwa wskazuje wstawia pomiędzy dwa warunki operator logiczny OR zamiast AND.

Wiemy już co nieco o argumentach, wwróćmy więc do naszej regułki:
[code]
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1/ [L,R=302]
[/code]

Reguła jak widzimy dodaje nam slash do końca adresu, po czym informuje, że dopasowanie jest ostatnim i nie przetwarzamy już dalej w tym cyklu [L] oraz przekierowujemy na adres ze slashem w koncówce [R=302] (tutaj finalnie powinniśmy dać 301, dla testów pozostawmy 302). Mając już pewność, że adres kończy się slashem na końcu, część wyrażenia:
[code]RewriteRule ^([^/.]+)/?$ index.php?action=$1[/code]
sprawdzająca wystąpienie, lub nie końcowego slasha może zostać zamieniona na:
[code]RewriteRule ^([^/.]+)/$ index.php?action=$1[/code]
Na razie jednak pozostawy to w niezmienionej formie.

Finalnie więc nasz .htaccess wygląda tak:
[code]
# .htaccess
RewriteEngine on

# blok1
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1/ [L,R=302]

# blok2
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^/.]+)/?$ index.php?action=$1
[/code]

Należy tutaj zrozumieć zasadę działania mechanizmu rewrite.
Otóż silnik rewrite leci po pliku .htaccess po koleji.
Polega to na tym, iż reguły z pliku przetwarzane są do skutku od początku do końca, aż do wystąpienia ostatniego pasującego dopasowania.
W naszym przypadku najpierw sprawdzany jest slash na końcu (blok 1), po czym po znalezieniu go, wyłaczamy dalsze przetwarzanie [L], następnie następuje przekierowanie na adres ze slashem [R=301] po czym cały proces przetwarzania pliku .htaccess zaczyna się od początku, ale tym razem mając już slash na końcu pierwsza reguła nie wykona się (nie dopasuje), wykona się jedynie ta z bloku 2, następnie po dopasowaniu jej (lub nie) przetwarzanie .htaccess zakończy się. Bardzo ważne jest zrozumienie tego mechanizmu, gdyż bez zrozumienia go prawie na pewno zdarzy się nam popadnięcie w błędną pętlę przy bardziej złożonych regułach.

Powyższy .htaccess w przypadku wpisania adresu:
[code]http://rewrite.localhost/kategorie[/code]

działa tak:
[code]
[URL] http://rewrite.localhost/kategorie
[PIERWSZY PRZEBIEG .htaccess] >> http://rewrite.localhost/kategorie/
[DRUGI PRZEBIEG .htaccess] >> http://rewrite.localhost/index.php?action=kategorie
[/code]

Diagram przedstawiający działanie mechanizmu Rewrite:

źródło: apache.org

I jego dokładniejsza wersja:

Dopasowania

Poki co zrobiliśmy jedno dopasowanie, do jednego parametru, dodajmy więc teraz więcej, podając np. ID kategorii:
Najpierw musimy obmyśleć jak skonstruowane będą nasze URL-e i wybrać jakąś logikę.
Chcemy sporządzić URL zawierający w sobie dwa elementy:
1) nazwę akcji (przykładowo: kategoria)
2) id przeglądanej kategorii

Adres taki może mieć więc taką postać, gdzie 'kategoria' to nazwa akcji, '41' to ID przegladanej kategorii:
[code]http://rewrite.localhost/kategoria/41[/code]

Adres taki tłumaczyć będziemy na adres wewnętrzny o postaci:
[code]http://rewrite.localhost/index.php?action=kategoria&id=41[/code]

Pierwszy problem: nasz URL może przybrać dwie możliwe formy:
[code]http://rewrite.localhost/kategorie[/code]
lub
[code]http://rewrite.localhost/kategoria/41[/code]
Musimy więc w jakiś sposób uwzględnić obie formy.
Jak tego dokonamy? Za pomocą dwóch reguł.

Zrobimy to tak:
[code]
# .htaccess
RewriteEngine on

# blok1 - dodajemy slash na końcu
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1/ [L,R=301]

# blok2 - nasze regułki
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2 [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/.]+)/?$ index.php?action=$1
[/code]

Pomijając resztę, nasze reguły wyglądają tak:
[code]
RewriteRule ^([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2 [L]
RewriteRule ^([^/.]+)/?$ index.php?action=$1
[/code]

Co się tutaj dzieje?
1) Najpierw dopasowujemy regułę dla dłuższego ciągu, z wystąpieniem numeru ID w adresie, jeśli dopasowanie zostanie wykonane, to parametr [L] mówi serwerowi, że jest to ostatnie przetwarzanie i żeby nie dopasowywał już kolejnej reguły,
2) Dopiero po sprawdzeniu powyższego sprawdzamy krótszą wersję, z podaniem samej akcji. Dlaczego ważna jest taka kolejność?
Akurat w tym przypadku wykonanie reguł odwrotnie nie sprawi problemu, ale przy bardziej złożonych regułach mogłoby to powodować problemy, gdyż pamiętajmy, że każda kolejna reguła pracuje na wyniku poprzedniej, a więc dopasowanie początkowe niejako określa wszystko to co poleci dalej do przetwarzania.
Dowód? Wykonajmy coś takiego:
[code]
RewriteRule ^(.+)/$ index.php?action=$1
RewriteRule ^([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2
[/code]
Usunęliśmy sprawdzenie wystąpienie slasha w środku adresu w pierwszej linijce w związku z czym pierwsza reguła zostanie dopasowana do:
[code]http://rewrite.localhost/kategoria/41[/code]
Do reguły kolejnej przekazany zostanie wynik dopasowanej pierwszej:
[code]index.php?action=kategorie/41[/code]
w związku z czym druga reguła nie wykona się nigdy!

Powróćmy więc do wersji poprawnej:
[code]
RewriteRule ^([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2 [L]
RewriteRule ^([^/.]+)/?$ index.php?action=$1
[/code]

Wynikiem w przypadku adresu:
[code]http://rewrite.localhost/kategoria/123[/code]
będzie wewnętrzne przekierowania na:
[code]index.php?action=kategoria&id=123[/code]

...natomiast w przypadku:
[code]http://rewrite.localhost/kategorie[/code]
będzie to:
[code]index.php?action=kategorie[/code]

Analogicznie zrobimy z np. 3 i więcej parametrami:
[code]
RewriteRule ^([^/.]+)/([^/.]+)/([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2&parametr3=$3&parametr4=$4 [L]
RewriteRule ^([^/.]+)/([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2&parametr3=$3 [L]
RewriteRule ^([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2 [L]
RewriteRule ^([^/.]+)/?$ index.php?action=$1 [L]
[/code]

Całość naszego .htaccess wyglądać więc może tak:
[code]
# .htaccess
RewriteEngine on

# blok1 - dodajemy slash na końcu
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1/ [L,R=301]

# blok2 - nasze regułki
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/.]+)/([^/.]+)/([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2&parametr3=$3&parametr4=$4 [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/.]+)/([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2&parametr3=$3 [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2 [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/.]+)/?$ index.php?action=$1 [L]
[/code]

Sprawdźmy teraz co się stanie, gdy wywołamy adres:
[code]http://rewrite.localhost/kategoria/123/aaa/bbb/ccc/ddd/eeee[/code]
Nie mamy żadnego wyrażenia dopasowującego taką ilość parametrów, serwer zwróci nam 404 Not Found.

Możemy jednak tego uniknąć, ignorując po prostu większą ilość parametrów podawanych między nadprogramowymi slashami:
Zmieńmy pierwszą regułę, zmieniając końcówkę jej dopasowania na:
[code].*/$[/code]
a więc na:
[code]RewriteRule ^([^/.]+)/([^/.]+)/([^/.]+)/([^/.]+).*/?$ index.php?action=$1&id=$2&parametr3=$3&parametr4=$4 [L][/code]
.* oznaczać będzie nam tutaj dowolny ciąg znaków, który może, ale nie musi nadprogramowo na końcu wystąpić.
Jest to bardziej eleganckie rozwiązanie, niż rzucenie błędem 404.
Możemy też pobrać nadprogramowy ciąg, przekazać go jako parametr do index.php, następnie przetworzyć przez PHP, albo stworzyć do obsłużenia tego oddzielne reguły, ja podałem jedynie przykład na jeden ze sposóbów radzenia sobie z niepasującymi do wzorca URL-ami. Inne sposoby przeanalizujemy później.

QSA - parametry GET w zapytaniu

A co jeśli wywołamy np. taki URL?
[code]http://rewrite.localhost/kategorie/?sort=desc[/code]
Po wykonaniu naszych przepisań, otrzymamy jedynie:
[code]index.php?action=kategorie[/code]
natomiast:
[code]?sort=desc[/code]
zostanie pominięte.

Jak więc przekazać parametry podane po znaku zapytania?
Służy do tego argument [QSA] - skrót od Query String Append.
Zmodyfikujmy teraz nasze reguły w .htaccess do takiej postaci:
[code]
# .htaccess
RewriteEngine on

# blok1 - dodajemy slash na końcu
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1/ [L,R=301]

# blok2 - nasze regułki, tym razem z uwzględnieniem QSA
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/.]+)/([^/.]+)/([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2&parametr3=$3&parametr4=$4 [L,QSA]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/.]+)/([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2&parametr3=$3 [L,QSA]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2 [L,QSA]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/.]+)/?$ index.php?action=$1 [L,QSA]
[/code]

Voila! Wynikiem przepisania:
[code]http://rewrite.localhost/kategorie/?sort=desc[/code]
jest:
[code]index.php?action=kategorie&sort=desc[/code]

Problem z prefixem "www."

Nieszczęsna pozostałość po starych czasach, czyli prefix, a właściwie subdomena 'www' może, ale nie musi wystąpić na początku naszego adresu.
Wszystko zależy jaki adres wywoła użytkownik. Niestety tak to już jest, że:
[code]http://www.rewrite.localhost[/code]
i
[code]http://rewrite.localhost[/code]
to (pomimo że prowadzą w to samo miesjce) dwa rożne adresy, zarówno dla plików cookies, czy polityki Same Domain Origin, a nawet dla robotów wyszukiwarek.
Co możemy z tym zrobić? Opcje są dwie:

1) usuwamy wszędzie "www." jeśli takowe wystąpi w adresie
2) dodajemy wszędzie "www." o ile nie występuje na początku adresu.

Wybor należy do nas, podaję oba rozwiązania:

1) usuwa "www." z każdego adresu:
[code]
RewriteCond %{HTTP_HOST} ^www. [NC]
RewriteRule ^(.*)$ http://rewrite.localhost/$1 [R=302,L]
[/code]

2) dodaje "www." do każdego adresu:
[code]
RewriteCond %{HTTP_HOST} !^www. [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=302,L]
[/code]

Uwaga: na czas testów dajemy tutaj przekierowanie 302, w finalnej wersji damy tutaj 301, czyli Moved Permamently.
Reguły te umieszczamy na początku, przed regułami dodającymi slasha do końcówki adresu:
[code]
# .htaccess
RewriteEngine on

# blok0 - usuwamy "www." z początku adresu
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{HTTP_HOST} ^www. [NC]
RewriteRule ^(.*)$ http://rewrite.localhost/$1 [R=302,L]

# blok1 - dodajemy slash na końcu
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1/ [L,R=302]

# blok2 - nasze regułki, tym razem z uwzględnieniem QSA
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/.]+)/([^/.]+)/([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2&parametr3=$3&parametr4=$4 [L,QSA]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/.]+)/([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2&parametr3=$3 [L,QSA]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/.]+)/([^/.]+)/?$ index.php?action=$1&id=$2 [L,QSA]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/.]+)/?$ index.php?action=$1 [L,QSA]
[/code]

Oczywiście konstrukcji takich jak powyżej nie tworzy się w praktyce, zamiast tego przekierowywuje się każdego requesta do jednego pliku PHP, który już sam dalej zajmuje się przeparsowaniem otrzymanego żądania:
[code]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .? index.php [L]
[/code]

No i to tyle w dzisiejszym odcinku.
Wiemy już jak przepisywać większą ilość parametrów w URL-u, jak używać atrybutów oraz na co zwracać uwagę przy tworzeniu regułek. W następnej części wykorzystamy to trochę bardziej praktycznie, a także poznamy kilka innych rozwiązań.

Poniżej jeszcze lista wszystkich argumentów jakie stosować można do regułek oraz najczęściej używanych zmiennych. Lista zaczerpnięta z http://4programmers.net/Z_pogranicza/Mod_rewrite

Argumenty - lista:

Znacznik [NC] (nocase)
Sprawia, że w danym wzorcu pomijane są różnice w wielkościach znaków. Dla przykładu, dwa poniższe wzorce mają identyczne działanie:
RewriteRule ^([A-Za-z])/?$ web.php?q=$1
RewriteRule ^([a-z])/?$ web.php?q=$1 [NC]
Znacznik R[=kod] (redirect)
Znacznik ten powoduje formalne przekierowanie wraz z podaniem kodu stanu HTTP, domyślnie powoduje on wysłanie kodu HTTP 302 Moved Temporarily. Przykład:
RewriteRule ^art/(\d+)/?$ art.php?id=$1 [R=301]
Kod w powyższym przykładzie to 301 Moved Permanently.
Używając tego znacznika można zwracać dowolny kod HTTP z zakresu od 300 do 400.
Znacznik F (forbidden)
Działa podobnie do znacznika redirect, ale od razu wysyła odpowiedź HTTP 403. Jeżeli w ramach jednej reguły znajdzie się ten znacznik oraz redirect, to pierwszeństwa na znacznik forbidden, co oznacza, że zostanie wysłany kod 403 niezależnie od wartości kodu redirect.
Znacznik G (gone)
Znacznik ten wysyła kod HTTP 410 - Usunięto, który informuje użytkownika o tym, że żądana strona została usunięta. Ma on pierwszeństwo przed znacznikiem redirect, ale ważniejszym od niego jest forbidden.
Znacznik L (last)
Znacznik ten pozwala na zatrzymanie przetwarzania reguł RewriteRule po skutecznym dopasowaniu adresu URL do reguły.
Znacznik N (next)
Znacznik next ponownie rozpoczyna proces przepisywania adresu od samego początku listy reguł. W momencie rozpoczęcia ponownego przetwarzania reguł obsługują one juz nie oryginalny adres URL, ale jego postać przepisano przez wszystkie reguły do momentu pojawienia się znacznika next.
Znacznik C (chain)
Jeżeli chcielibyśmy traktować blok reguł jako jednostkę, to powinniśmy posłużyć się znacznikiem chain. Wytłumaczmy to na przykładzie:
Rewrite Rule ^art/(\d+)/?$ art.php?id=$1 [C]
RewriteRule ^cat/(\w+)/?$ cat.php?cat=$1 [C]
RewriteRule ^art/[^\d+]/?$ error.php
Jeżeli żadna z reguł związanych znacznikiem chain nie pasuje to przechodzimy do ostaniej.
Znacznik S=liczba (skip)
Ten znacznik powoduje pominięcie podanej liczby reguł. Znacznik ów zachowuje podobnie się do chain, z tą różnicą, że pozwala pominąć reguły w przypadku udanego dopasowania.
Znacznik T=typ-mime (type)
W przypadku kiedy chcemy zmienić typ MIME wysyłanego dokumentu, to możemy posłużyć się tym znacznikiem. Na przykład jeżeli mamy pliki xhtml i chcielibyśmy wysłać je za pomocą poprawnego typu MIME (application/xhtml+xml) to możemy wykorzystać tą regułę:
RewriteRule ^.+\.xhtml$ - [T=application/xhtml+xml]
Znacznik CO=nazwa:wartość:domena[:czaszycia[:sciezka]] (cookie)
Znacznik ten służy do utworzenia ciasteczka w przeglądarce użytkownika . Wymagane są pola nazwa, wartość i domena. Możemy na przykład utworzyć ciasteczko o nazwie bylemtu, istnienie którego będzie oznaczało że użytkownik już odwiedzał naszą stronę.
RewriteRule ^index\.php$ - [CO=bylemtu:true:domena.pl]
Znacznik E=zmienna:wartosc (env)
Znacznik ten pozwala nadać wartość zmiennej środowiskowej zmienna. W jednej grupie znaczników można przypisać wartości do wielu zmiennych środowiskowych.
Znacznik QSA (qsappend)
W przypadku obecności tego znacznika mechanizm przepisywania pobierze oryginalny ciąg znaków zapytania i dopisze do niego ciąg znaków wygenerowany przez regułę.
RewriteRule ^index\.php$ index.php?zmienna=wartosc [QSA]
Jeżeli tej regule podamy adres postaci index.php?cos=bla to w wyniku jej działania otrzymamy index.php?zmienna=wartosc&cos=bla.
Znacznik NE (noescape)
Znacznik ten pomaga unikać automatycznego wyróżniania znaków specjalnych.
Znacznik PT (passtrough)
Używamy go w momencie kiedy chcemy połączyć moduł mod_rewrite z innymi moduła, które również zajmują się obsługą adresó URL.
Znacznik NS (nosubreq)
Znacznik ten używamy w momencie jeżeli chcemy aby mechanizm przepisywania adresów pominął regułę, jeżeli żądanie jest wewnętrznym żądaniem podrzędnym. Bardzo rzadko jest używany, jezeli korzystamy z Apache i PHP, przydaje się w momencie dołączenia skryptów CGI.
Znacznik P (proxy)
Nakazuje on zakończenie przetwarzania reguł i przekazanie danych żądania do modułu mod_proxy.

Zmienne:

HTTP_USER_AGENT Ciąg znaków z informacja identyfikującą przeglądarke.
HTTP_REFERER Dokładnie "polecający", adres strony, która nas skierowała, na konkretną stronę. Nie wszystkie przeglądarki wysyłają, również firewall'e często wycinają to.
HTTP_COOKIE Ciąg znaków ciasteczka.
HTTP_FORWARDER Jeżeli żądanie jest obsługiwane przez serwer proxy, to zawiera dowolne przekazywane informacje.
HTTP_HOST Nazwa komputera wymieniana w rządaniu.
HTTP_PROXY_CONNECTION Zwraca zawartość nagłówka Proxy-Connection.
REMOTE_ADDR Adres ip komputera wysłającego żądanie.
REMOTE_HOST Nazwa komputera wysyłającego żądanie.
REMOTE_USER Nazwa użytkownika komputera wysyłającego żądanie. Nie musi być podana.
REMOTE_IDENT Zmienne przeznaczone do celów indentyfikacji. Może zawierać nazwę użytkownika.
REMOTE_METHOD Metoda żądania pliku (POST lub GET).
SCRIPT_FILENAME Pełna lokalna ścieżka do żądanego pliku.
PATH_INFO Dodatkowe informacje o ścieżce.
QUERY_STRING Ciąg zapytania albo parametry zapytania metodą GET.
AUTH_TYPE Rodzaj uwierzytelniania.
DOCUMENT_ROOT Katalog główny strony.
SERVER_ADMIN Adres email administratora serwera.
SERVER_ADDR Adres ip lub komputera serwera.
SERVER_PORT Podany w żądaniu port serwera.
SERVER_PROTOCOL Nazwa i wersja protokołu żądania.
SERVER_SOFTWARE Nazwa oprogramowania serwera.
TIME_YEAR Rok na serwerze.
TIME_MON Numer miesiąca.
TIME_DAY Numer dnia.
TIME_HOUR Godzina żądania.
TIME_MIN Minuta żądania.
TIME_SEC Sekunda żądania.
TIME_WDAY Dzień tygodnia żądania.
TIME Bierząca godzina.
API_VERSION Numer wersji interfejsu API serwera Apache.
THE_REQUEST Pełne żądanie HTTP.
REQUEST_URI Żądany zasób.
REQUEST_FILENAME Pełna ścieżka w lokalnym systemie plików do żądanego pliku.
IS_SUBREQ Informacja, czy żądanie jest wewnętrznym żądaniem podrzędnym.
HTTPS Wartość on oznacza, że połączenie jest szyfrowane.

Pełna lista tutaj:

http://www.askapache.com/htaccess/mod_rewrite-variables-cheatsheet.html

[APACHE][mod_rewrite] Wstęp do przepisywania URL-i

2015-05-24T23:42:00.000+02:00

Mechanizm przepisywania URL-i za pomocą modułu rewrite z początku może wydawać się nieco skomplikowany. O ile nauczenie się podstawowych regułek przepisywania i wykorzystanie ich w praktyce nie stanowi zbyt dużego problemu, to niestety, ale prędzej, czy później natrafimy na kilka problemów związanych z regułami przekierowań, na pewno też nie raz i nie dwa "zapętlimy się" przy co bardziej rozbudowanej hierarchi regułek. W artykułach tutaj postaram się przedstawić najczęstsze problemy z jakimi prawie na pewno spotkamy się podczas tworzenia plików .htaccess. Omówię też same podstawy tworzenia takich przekierowań. Zacznijmy więc może od początku - czym jest mod_rewrite? Jest to moduł serwera Apache, ktory za pomocą odpowiednio określonych warunków (conditions) wywołuje zadaną przez nas regułę (rule), która w dany, określony sposób dokonuje przekierowania z jednego URL-a na inny, zdefiniowany przez nas. Reguły takie określamy w specjalnym pliku o nazwie '.htaccess', który umieszczamy w folderze, dla którego zawarte w nim reguły mają obowiązywać (będą też obowiązywać dla jego podfolderów). Plik '.htacccess' ma ściśle określoną strukturę, składającą się z kilku sekcji. Omówimy je kilka akapitów niżej. Na razie omówmy samą zasadę przepisywania URL-i, a więc - na czym to wszystko polega?

Wyobraźmy sobie, że mamy przygotowaną w PHP aplikację, np. sklep internetowy.
W aplikacji tej posiadamy system kategorii i podkategorii naszych produktów, listę tych produktów, oraz odpowiednie sekcje odpowiadające za wyświetlanie informacji o zadanym produkcie.
Po sklepie tym poruszamy się w jakiś określony sposób definiujący nam np. gdzie obecnie się znajdujemy (czy np. w widoku listy kategorii, czy produktów) oraz jaką kategorię lub produkt obecnie wyświetlamy. Informacje takie przekazujemy zazwyczaj jako parametry w adresie, np.
[code]http://nasz_sklep.com/index.php?action=category&id=20[/code]
lub
[code]http://nasz_sklep.com/index.php?action=product_info&id=45[/code]

Brzydkie prawda? A i niezbyt chętnie indeksowane przez wyszukiwarki.
O wiele ładniej wygladałoby to, gdyby linki przedstawiały się np. tak:
[code]http://nasz_sklep/kategorie/telewizory[/code]
lub
[code]http://nasz_sklep/produkt/Samsung_Smart_LED_J6200.html[/code]

...albo jeszcze lepiej:
[code]http://nasz_sklep/telewizory[/code]
lub
[code]http://nasz_sklep/telewizory/LED/Samsung_Smart_LED_J6200.html[/code]

Dzięki mod_rewrite możemy uzyskać właśnie takie linki i wiele wiele więcej.
Na czym polega takie zamiana? Otóż, zauważmy, iż każdy z naszych wewnętrznych linków ma jakąś określoną strukturę, np. w linku
[code]?action=category&category_id=20[/code]
parametr 'action' przechowuje nam informacje o rodzaju oglądanej sekcji (akcji), w tym przypadku jest to widok kategorii produktów, natomiast parametr category_id mówi naszej aplikacji o numerze ID kategorii jaką wlaśnie przeglądamy. Zarazem parametr 'action' jest tutaj niejako stałym elementem takiego linka. Zmienia się jedynie to co występuje w jego wartości, np.:

[code]index.php?action=category
index.php?action=product_info
index.php?action=order_info[/code]

itd...

Analogicznie jest z parametrem 'id', który przechowuje nam numer ID oglądanego zasobu:
[code]index.php?action=product_info&id=1
index.php?action=product_info&id=54
index.php?action=product_info&id=437[/code]
itd...

Struktura naszego linka przedstawia się więc następująco:
[code]http://nasz_sklep.com/index.php?action=NAZWA_WYŚWIETLANEJ_AKCJI&id=ID_POKAZYWANEGO_ELEMENTU[/code]

Załóżmy teraz, że chcemy taki link sprowadzić do bardziej ładnej wersji, np. do takiej formy:
[code]http://nasz_sklep.com/NAZWA_WYŚWIETLANEJ_AKCJI/ID_POKAZYWANEGO_ELEMENTU[/code]

Jak tego dokonać? Otóż musimy utworzyć:
1) jakiś warunek sprawdzający jak nasz URL wygląda
2) jakąś regułę, która na podstawie tego warunku dokona odpowiedniej zamiany

Budowa pliku .htaccess

Zacznijmy od zapoznania się z przykładową budową pliku .htaccess, który będzie przepisywać nasze URL-e. Plik taki składa się z kilku sekcji, które po koleji sobie omówimy. Zacznijmy więc, poniżej przykładowy plik .htaccess:
[code]
RewriteEngine on //1
RewriteCond %{REQUEST_FILENAME} !-f //2
RewriteRule ^([^/.]+)/?$ index.php?action=$1 //3[/code]

Ten prosty plik dokonuje po koleji następujących działań:
1) włącza moduł rewrite dla tego folderu i jego podfolderów
2) sprawdza warunek, czy nie odwołujemy się do istniejącego na serwerze pliku
3) jeśli powyższy warunek jest spełniony to przepisuje URL z postaci:
[code]nasz_sklep.com/NAZWA_AKCJI/[/code]
na
[code]index.php?action=NAZWA_AKCJI[/code]

RewriteCond

O ile pierwsza linijka nie wymaga zbytniego tłumaczenia, tak dalej sprawa robi się już bardziej skomplikowana. Przeanalizujmy wiec wszystko po koleji, na początek warunek zawarty w linijce drugiej:

[code]RewriteCond %{REQUEST_FILENAME} !-f[/code]

warunki dla danej reguły definiujemy na zasadzie:

[code]RewriteCond NASZ_WARUNEK1
RewriteCond NASZ_WARUNEK2
RewriteCond NASZ_WARUNEK3
itd...[/code]

Każdy z warunków musi znaleźć się w oddzielnej linijce.
Jeśli dany warunek zostaje spełniony, to silnik przeskakuje do następnej linijki i albo spradza kolejny warunek, albo natrafia na blok z regułą, tak jak w naszym przykładzie, gdzie warunek mamy tylko jeden. W przypadku podania większej ilości warunków - wszystkie one muszą zostać spełnione, aby wykonała się reguła po nich następująca. Poprzedzające regułę warunki obowiązują tylko dla pierszej reguły po nich występującej!

Ogólna zasada działania prezentuje się więc tak:
[code]WARUNEK1
WARUNEK2
WARUNEK3
REGUŁA1 (jeśli WARUNKI 1,2, i 3 spełnione)

WARUNEK4
REGUŁA2 (jeśli WARUNEK4 spełniony)
REGUŁA3 (kolejna reguła, tutaj już nie obowiązuje WARUNEK4)[/code]

itd...
gdzie dana reguła wykona się jedynie wtedy, gdy określone przed nią warunki zostaną dla danej reguły spełnione.
W naszym przykładzie mamy na początek jedynie jedną regułę:
[code]RewriteCond %{REQUEST_FILENAME} !-f[/code]
która sprawdza, czy przypadkiem nie odwołujemy się do istniejącego pliku.
Dlaczego taka reguła? Już wyjaśniam. Załóżmy, że nasz plik .htaccess znajduje się w katalogu głównym naszej strony, przy czym w tym samym katalogu znajduje się plik o nazwie 'kategorie'. Mało prawdopodone, ale wyobraźmy sobie, że jednak plik 'http://nasz_sklep.com/kategorie' istnieje realnie w tym miejscu. Zarazem słowo 'kategorie' jest tutaj jednym z parametrów jakie przyjmuje nasza zmienna $_GET['action'].

Mamy więc tutaj kolizję, gdyż adres 'http://nasz_sklep.com/kategorie' może odwoływac się zarówno do realnie istniejącego pliku o nazwie:
[code]http://nasz_sklep.com/kategorie[/code]
jak i do przepisanego URL-a:
[code]http://nasz_sklep.com/index.php?action=kategorie[/code]

Jak więc rozwiązać ten problem? Od tego właśnie mamy tutaj nasz warunek.
Sprawdza on, czy plik o zadanej w adresie nazwie nie istnieje fizycznie w obecnym katalogu i dopiero jeśli takowego pliku nie ma, to wykonywana jest reguła przepisująca adres:
[code]http://nasz_sklep.com/kategorie[/code]
na
[code]http://nasz_sklep.com/index.php?action=kategorie[/code]

Rozłóżmy ten warunek na czynniki pierwsze:
[code]%{REQUEST_FILENAME} !-f[/code]

%{REQUEST_FILENAME} - jest to zmienna środowiskowa przechowująca wywoływany właśnie adres, w naszym przypadku np. http://nasz_sklep.com/kategorie
-f - tóż po niej podany jest parametr -f, który oznacza lokalny plik.

Podany jest on jednak ze znakiem negacji (wykrzyknik - !), a więc tłumacząc na zrozumiały język warunek brzmi następująco:
[code]WYWOŁYWANY ADRES != REALNIE ISTNIEJACY PLIK O TAKIEJ NAZWIE[/code]
a więc: jeśli nie istnieje plik o nazwie takiej jak wywoływany URL, to warunek zostaje spełniony i lecimy dalej, wywołać regułę w linijce trzeciej.

W zasadzie zawsze jako startowe reguły podaje się właśnie sprawdzenie, czy wywoływany adres nie prowadzi do istniejącego pliku lub folderu:

[code]%{REQUEST_FILENAME} !-f
%{REQUEST_FILENAME} !-d[/code]

Parametr -f oznacza plik, parametr -d oznacza folder.
Wzbogaćmy więc nasz .htaccess o sprawdzenie folderu:

[code]
RewriteEngine on //1
RewriteCond %{REQUEST_FILENAME} !-f //2
RewriteCond %{REQUEST_FILENAME} !-d //3
RewriteRule ^([^/.]+)/?$ index.php?action=$1 //4
[/code]

Tego typu zmiennych jest więcej, np.
%{HTTP_HOST} - przechowywuje część z adresu z nazwą hosta, przykładowo: po wywołaniu http://nasz_sklep.com/kategorie w zmiennej tej znajdzie się 'nasz_sklep.com'.

%{REQUEST_URI} - przechowuje cały URL z jakiego nastąpiło wywołanie.

RewriteRule

Skoro oba warunki mamy spełnione (nie istnieje plik 'http://nasz_sklep.com/kategorie' oraz nie istnieje folder 'http://nasz_sklep.com/kategorie') to wykonywana jest następująca po warunku reguła:

[code]RewriteRule ^([^/.]+)/?$ index.php?action=$1[/code]

Rozłóżmy ją na czynniki pierwsze.
W pierwszym członie:
[code]^([^/.]+)/?$[/code]
znajduje się wyrażenie, z którego będziemy przepisywać URL, tutaj np.:

[code]http://nasz_sklep.com/kategorie[/code]

w drugim natomiast forma do jakiej przepisanie nastąpi:
[code]index.php?action=$1[/code]

Regułka ma postać:
[code]RewriteRule ADRES_WYWOŁANY PRAWDZIWY_ADRES [atrybuty/flagi][/code]

Pierwszy człon reguły jest wyrażeniem regularnym.
Aby więc móc umiejętnie wykorzystywać reguły przypisań nieobca musi nam być wiedza dotycząca stosowania wyrażeń regularnych. Na potrzeby tego poradnika zakładam, że jesteś z wyrażeniami regularnymi zapoznany i umiesz używać ich w praktyce.

Przyjrzyjmy się dopasowywanemu ciągowi:

[code]^([^/.]+)/?$[/code]

Po koleji:

^ - początek adresu, wystąpi on zaraz po http://nasza_strona.com
/?$ - nasz adres może, ale nie musi kończyć się slashem (znak zapytania określa, że znak przed nim może wystąpić lub nie)
[^/.]+ - mamy tutaj dopasowywany zakres znaków, w którym na początku nie może wystąpić slash (znak negacji ^), następnie może wystąpić dowolna ilość znaków (kropka .), a całość takiej konstrukcji musi wystąpić conajmniej raz (znak + zastosowany dla podanego zakresu)
([^/.]+) - dopasowane wyrażenie jest następnie wzięte w nawiasy okrągłe. Zawartość dopasowania objęta w nawiasy zostanie przypisana do zmiennej $1 w następnym członie.

Pamiętajmy, że dopasowywany zawsze w RewriteRule ciąg jest jedynie tą częścią adresu, która występuje po nazwie hosta, a więc w naszym przypadku wszystko to co występuje po 'http://nasz_sklep.com/'. Jeśli chcemy dostać się do części z nazwą hosta wykorzystajmy zmienną %{HTTP_HOST}.

Takich dopasowań możemy zrobić więcej, w przypadku takim każde kolejne dopasowanie wzięte w nawias będzie tworzyło odpowiednio kolejną zmienną, czyli $1, $2, $3 itd.

Czas na drugą część wyrażenia:
[code]index.php?action=$1[/code]
określa ono co robimy z uzyskanym w pierwszej części dopasowaniem.
W naszym przypadku przepisujemy adres na:
[code]index.php?action=$1[/code]
co jest równoważne z:
[code]index.php?action=DOPASOWANE_W_NAWIASACH_WYRAŻENIE[/code]
czyli z:
[code]index.php?action=([^/.]+)[/code]

Wywołując więc adres:
[code]http://nasz_sklep.com/kategorie[/code]
nasza reguła za pomocą wyrażenia regularnego dopasowywuje z niego ciąg 'kategorie', umieszcza go w zmiennej $1, a następne zmienną tą przekazuje jako parametr do:
[code]index.php?action=$1[/code]
generując tym samym adres:
[code]index.php?action=kategorie[/code]

Finalnie, efektem naszego działania będzie to, iż użytkownik wpisujący w przeglądarkę adres:
[code]http://nasz_sklep.com/kategorie[/code]
tak naprawdę trafia do lokacji:
[code]index.php?action=kategorie[/code]
Takie przekierowanie jest oczywiście "przezroczyste" dla użytkownika, w pasku adresu pozostaje wciąż adres 'http://nasz_sklep.com/kategorie'.
Przepisywany URL jest widoczny jedynie wewnętrznie dla serwera oraz dla naszej aplikacji w PHP.

To tyle tytułem krótkiego wstępu do silnika rewrite.
Wiemy już mniej więcej na czym polega działanie mod_rewrite i do czego służy.
W nastepnych artykułach przeanalizujemy bardziej złożone reguły i nauczymy się trochę bardziej skomplikowanych aspektów przepisywania URL-i.

Tester online reguł mod_rewrite znajduje się tutaj:
http://htaccess.madewithlove.be/

[PHP] Namespaces - przestrzenie nazw w PHP

2015-05-24T20:41:00.000+02:00

Zapewne spotkaliśmy się już z dziwnie wyglądającymi nazwami klas w PHP, np. podczas pracy z frameworkami, takimi jak Symfony. Przykładowa nazwa klasy mogła wyglądać np. tak: 'Bundle\HelloBundle\Controller\HelloController'. Nie ma tu jednak żadnej pokręconej magii, a jedynie przestrzeń nazw. Klasa w tym przypadku to 'HelloController', a wszystko to co znajduje się przed nią to jej przestrzeń nazwowa. Korzystanie z przestrzeni nazw znacznie usprawnia pracę z kodem, a także eliminuje problem kolizji, gdzie dwie klasy mogą mieć identyczne nazwy. Pozwalają one również na stworzenie bardzo fajnej i przejrzystej hierarchi naszego kodu. W tym krótkim tutorialu dowiemy się czym są i jak poprawnie używać przestrzeni nazw w PHP. Funkcjonalność ta niczym nie różni się od tego samego rozwiązania stosowanego od zarania dziejów w językach takich jak C, czy Java. Przestrzenie nazw w PHP zostały dodane w wersji 5.3.

Przestrzeń globalna

Jest główną przestrzenią nazw. Zauważmy, że bardzo często piszemy sobie jakieś klasy, czy też funkcje, bądź też korzystamy z tych wbudowanych w silnik PHP.
Korzystamy np. z funkcji 'header()' służacej do ustawienia nagłówka, funkcji 'strip_tags()' służącej do obcięcia tagów HTML i wielu innych. Nazewnictwo tych funkcji jest proste i składa się z jednego członu określającego nazwę funkcji. Funkcje takie istnieją w domyślnej przestrzeni nazw i są dostępne wszędzie w naszym kodzie. Podobnie jest z klasami, ich metodami i właściwościami. Nie wymagają poprzedzania ich nazwy nazwą przestrzeni w jakiej występują, gdyż globalna przestrzeń jest tą domyślną, bazową. Wyobraźmy sobie teraz, że tworzymy własną klasę, np. niech to będzie klasa o nazwie:

[code]MyClass {}[/code]

Tworzymy sobie plik z klasą, który będzie zamierał definicję naszej klasy, jednej funkcji i jednej stałej, niech będzie to np. plik 'classes/MyClass.php'.
W pliku tym stworzymy sobie definicję dla naszej klasy:

[code]
<?php
// classes/MyClass.php

const MYCONST = 'classes/MyClass.php';

function MyFunction()
{
return __FUNCTION__;
}

class MyClass {

public function MyMethodName()
{
return __METHOD__;
}

public function MyClassName()
{
return __CLASS__;
}

public static function SayHello()
{
return 'Hello from ' . __CLASS__ . '::' . __METHOD__;
}
}
?>
[/code]

Plik z klasą dołączymy do naszego głównego pliku, niech będzie to plik "index.php".
Następnie utworzymy nowy obiekt tejże klasy i wywołamy metodę 'GetMethodName()', która zwróci nam nazwę naszej metody w klasie 'MyClass':

[code]
<?php
// index.php
require_once('classes/MyClass.php');

echo MYCONST; // WYNIK: classes/MyClass.php
echo 'Function name:' . MyFunction(); // WYNIK: MyFunction

$c = new MyClass;
echo 'Method name:' . $c->MyMethodName(); // WYNIK: Method name: GetMethodName
echo 'Class name:' . $c->MyClassName(); // WYNIK: Class name: MyClass
echo MyClass::SayHello(); // WYNIK: Hello from MyClass::SayHello
?>
[/code]

Jak widzimy, na początku wyświetlamy stałą, potem nazwę funkcji, następnie klasę - jest to prościutka klasa, z trzema metodami zwracającymi odpowiednio:
- nazwę wywoływanej metody
- nazwę wywoływanej klasy
- tekst przywitania z przedstawieniem się

W tym prostym przypadku nie zdeklarowaliśmy żadnej przestrzeni nazw, nasza klasa istnieje zatem w przestrzeni globalnej.
Możemy utworzyć jej obiety w dowolnym miejscu w kodzie. A co jeśli teraz stworzymy kolejną klasę o takiej samej nazwie? Stwórzmy plik 'other_classes/MyClass.php' zawierający identyczną definicję klasy co 'classes/MyClass.php' i dołączmy do naszego 'index.php':
[code]
<?php
// index.php
require_once('classes/MyClass.php');
require_once('other_classes/MyClass.php');

echo MYCONST;
echo 'Function name:' . MyFunction();

$c = new MyClass;
echo 'Method name:' . $c->MyMethodName();
echo 'Class name:' . $c->MyClassName();
echo MyClass::SayHello();

// WYNIK: Fatal error: Cannot redeclare class Users
?>
[/code]
Działanie takie spowoduje błąd, gdyż staramy się zdefiniować dwie takie same klasy w jednej i tej samej przestrzeni nazw (tutaj - w globalnej). Do rozwiązania tego problemu wykorzystamy właśnie oddzielne przestrzenie nazw.

NAMESPACE

Przestrzeń nazw definiujemy za pomocą wyrażenia:
[code]namespace NAZWA_PRZESTRZENI;[/code]

Deklaracja taka musi się znaleźć zaraz na początku pliku - należy o tym pamiętać.
Blok kodu jaki wystąpi po deklaracji przestrzeni nazw może należeć jednocześnie jedynie do jednej przestrzeni, jednakże możemy w jednym pliku zawrzeć kilka przestrzeni i bloków kodu:

[code]
<?php
namespace MyApp1;
// blok kodu dla MyApp1

namespace MyApp2;
// blok kodu MyApp2

namespace MyApp3;
// blok kodu dla MyApp3
?>
[/code]
Nie polecam jednak takiego rozwiazania - my będziemy stosować po jednej przestrzeni na jeden plik.

Wyobraźmy sobie, że nasza aplikacja webowa ma nazwę 'MyApp' i jest podzielona na jakieś elementy. Jednym z elementów moze być obsługa kont użytkowników, innym dostęp do bazy danych, jeszcze innym moduł do wyświetlania artykułów.

Kod takich elementów zapewne rozmieścilibyśmy sobie w aplikacji mniej więcej w taki sposób:
- classes/Users.php
- classes/DB.php
- classes/Articles.php
itd.

Idąc takim pomysłem, stwórzmy sobie nową klasę, o nazwie np. 'Users' i zapiszmy w pliku 'classes/Users.php', ale tym razem dołączmy do niej przestrzeń nazw o nazwie np. 'MyApp\Users'.
Stwórzmy naszą klasę:

[code]
<?php
// classes/Users.php

namespace MyApp\Users;

class Users {

public function MyMethodName()
{
return __METHOD__;
}

public function MyClassName()
{
return __CLASS__;
}

public static function SayHello()
{
return 'Hi, I\'m users class: ' . __CLASS__;
}
}
?>
[/code]

Na samym początku stworzyliśmy tutaj przestrzeń nazw o nazwie 'MyApp\Users'.
Zauważmy, że na początku podaliśmy 'MyApp', następnie po backslashu (\) podaliśmy 'Users'.
Taka właśnie jest konwencja nazewnictwa w przestrzeniach nazw, nic nie stoi na przeszkodzie, abyśmy następne przestrzenie nazywali jeszcze bardziej hierarchicznie, jak np.:
'MyApp\Users\Actions\AddUsers'

Załączmy teraz utworzoną klasę do naszego 'index.php' i spróbujmy wywołać metodę 'Users::SayHello()':
[code]
<?php
// index.php
require_once('classes/Users.php'); // dołączamy klasę Users
echo Users::SayHello(); // WYNIK: Fatal error: Class 'Users' not found!
?>
[/code]

Wywołanie pliku 'index.php' wyświetliło nam błąd informujący o tym, że klasa 'Users' nie istnieje!
Ale zaraz, zaraz - przecież właśnie ja stworzyliśmy i załączyliśmy do pliku 'index.php'. W czym więc problem? Otóż problem w tym, że nasza klasa istnieje, ale w przestrzeni nazw o nazwie 'MyApp\Users'. Nie istnieje natomiast w przestrzeni globalnej naszego kodu.

Zmodyfikujmy teraz lekko nasz 'index.php' i zmienmy jego kod na:
[code]
<?php
// index.php
require_once('classes/Users.php'); // dołączamy klasę Users
echo \MyApp\Users\Users::SayHello(); // WYNIK: Hi, I'm users class: MyApp\Users\Users
?>
[/code]

Voila! Zadziałało, mamy dostęp do klasy Users.
Czego więc tutaj naprawdę dokonaliśmy? Otóż poprzedziliśmy nazwę wywoływanej klasy jej przestrzenią nazw.
Zauważmy więc, że nasza klasa 'Users' istnieje TYLKO I WYŁĄCZNIE w swojej przestrzeni i tylko w taki sposób możemy się do niej odwołać.

Wyjaśnienia wymaga:
[code]\MyApp\Users\[/code]
Otóż tym zapisem podaliśmy prefix naszej klasy, czyli jej przestrzeń nazw, dopiero po tym prefixie właściwą nazwę klasy. Zapis ten rozpoczęliśmy jednak od backslasha (\) - co to oznacza? Oznacza to to, że pierwszy backslash zawsze oznacza przestrzeń główną, bazową, tą położoną najwyżej w hierarchi. Jej nazwa jest pusta, więc podajemy ją jedynie za pomocą jednego backslasha na początku.

Wykonajmy teraz podobny manewr co wcześniej i stwórzmy drugą, identyczną klasę o nazwie 'Users', ale w innej przestrzeni nazw. Stwórzmy np. plik 'other_classes/Users.php' i wpiszmy do niego to samo co w poprzedniej klasie 'Users', zmieńmy jednak jego przestrzeń nazw:

[code]
<?php
// other_classes/Users.php

namespace MyApp\OtherUsers;

class Users {

public function MyMethodName()
{
return __METHOD__;
}

public function MyClassName()
{
return __CLASS__;
}

public static function SayHello()
{
return 'Hi, I\'m users class: ' . __CLASS__;
}
}
?>
[/code]

Załączmy definicję klasy do naszego 'index.php' i zobaczmy co się stanie:
[code]
<?php
// index.php
require_once('classes/Users.php'); // dołączamy klasę Users (z przestrzeni MyApp/Users)
require_once('other_classes/Users.php'); // dołączamy klasę Users (z przestrzeni MyApp/OtherUsers)
echo \MyApp\Users\Users::SayHello(); // WYNIK: Hi, I'm users class: MyApp\Users\Users
echo '<br />';
echo \MyApp\OtherUsers\Users::SayHello(); // WYNIK: Hi, I'm users class: MyApp\OtherUsers\Users
?>
[/code]

Jak widać - tym razem nie spowodowaliśmy błędu załączając dwie identyczne klasy o takich samych nazwach. Stało się to dlatego, iż obie klasy 'Users' istnieją w oddzielnych przestrzeniach nazw.
Dostęp do każdej z nich natomiast uzyskujemy za pomocą podania ich przestrzeni nazw przed właściwą nazwą.

USE

Dostęp do klasy lub funkcji z danej przestrzeni nazw można uzyskać również w formie prostrzej, wykorzystując do tego celu dyrektywę 'use'. Na czym to polega? Otóż dyrektywa 'use' podana w kodzie informuje PHP o tym, z jakiej przestrzeni nazw obecnie chcemy korzystamy. Prześledźmy to na przykładzie, modyfikując nasz plik 'index.php':

[code]
<?php
// index.php
use MyApp\Users\Users; // informujemy o używaniu przestrzeni \MyApp\Users
require_once('classes/Users.php'); // dołączamy klasę Users (z przestrzeni MyApp/Users)
require_once('other_classes/Users.php'); // dołączamy klasę Users (z przestrzeni MyApp/OtherUsers)

echo Users::SayHello(); // WYNIK: Hi, I'm users class: MyApp\Users\Users
?>
[/code]

Jak widać powyżej, poinformowaliśmy PHP o tym, że korzystamy obecnie z przestrzeni '\MyApp\Users' i dzięki temu w odwołaniu do klasy 'Users' nie musimy już podawać jej przestrzeni nazw.
Dyrektywa use zaczyna obowiązywać od miejsca jej użycia w kodzie.
Co za tym idzie, zapis:
[code]
<?php
// index.php
require_once('classes/Users.php'); // dołączamy klasę Users (z przestrzeni MyApp/Users)
require_once('other_classes/Users.php'); // dołączamy klasę Users (z przestrzeni MyApp/OtherUsers)

echo Users::SayHello();
use MyApp\Users\Users;
?>
[/code]
będzie niepoprawny i spowoduje błąd.

Po słowie 'use' nie podajemy backslasha na początku nazwy.
Możemy jednocześnie korzystać z kilku przestrzeni nazw, podając je po przecinku, wg zasady:
[code]use namespace1, namespace2, namespace3.....;[/code]

Aliasy nazw

Istnieje jeszcze jedno ciekawe usprawnienie związane z przestrzeniami nazw, mianowicie aliasy nazw. Wyobraźmy sobie, że stworzyliśmy sobie długą, hierarchiczną przestrzeń nazw:

[code]MyApp\UsersAccounts\Actions\AddUsers[/code]

a w niej dopiero klasę o nazwie 'Users'.

Wywołanie tej klasy w naszym kodzie będzie dość długie, np:

[code]$user = new \MyApp\UsersAccounts\Actions\AddUsers\Users;[/code]

Aby nie pisać tak długich konstrukcji (a przecież mogą być jeszcze dłuższe) wykorzystamy aliasy, czyli chwilowe zastąpienie nazwy naszej przestrzeni za pomocą skróconej nazwy pod jaką będzie ona dostępna w kodzie. Użycie aliasu wygląda następująco:
[code]use NAZWA_PRZESTRZENI as ALIAS[/code]

w naszym przypadku zróbmy więc:
[code]use MyApp\UsersAccounts\Actions\AddUsers as U;[/code]

Od tej chwili do przestrzeni 'MyApp\UsersAccounts\Actions\AddUsers' możemy odwoływać się stosując formę skróconą 'U'. Prześledźmy w praktyce (zakładając, że dołączamy klasę z przestrzeni MyApp\UsersAccounts\Actions\AddUsers):

[code]
<?php
// index.php
use MyApp\UsersAccounts\Actions\AddUsers as U; // informujemy o używaniu przestrzeni MyApp\UsersAccounts\Actions\AddUsers pod aliasem U
require_once('classes/Users.php'); // dołączamy klasę Users (z przestrzeni nazw MyApp\Users\Actions\AddUsers)

echo U\Users::SayHello(); // WYNIK: Hi, I'm users class: MyApp\UsersAccounts\Actions\AddUsers\Users
?>
[/code]

Możemy też stworzyć alias bezpośrednio dla klasy (pamiętajmy, że sposób działa tylko dla klas, dla funkcji i zmiennych nie zadziała!):
[code]
<?php
// index.php

use MyApp\UsersAccounts\Actions\AddUsers\Users as Obj; // tworzymy alias do klasy
require_once('classes/Users.php'); // dołączamy klasę Users (z przestrzeni nazw MyApp\UsersAccounts\Actions\AddUsers)

echo Obj::SayHello(); // WYNIK: Hi, I'm users class: MyApp\UsersAccounts\Actions\AddUsers\Users
?>
[/code]

__autoload

Jak zapewne już zauważyliśmy, hierarchiczne nazewnictwo przestrzeni nazw przypomina coś co znamy na codzień - strukturę folderów. Spostrzeżenie jak najbardziej poprawne, gdyż właśnie w ten sposób jest to wykorzystywane. Standardem w obecnych frameworkach jest rozmieszczenie plików z klasami w folderach odpowiadającym ich hierarchicznej strukturze. Przykładowo, klasę 'Users' zdeklarowaną w przestrzeni nazw 'MyApp\UsersAccounts\Actions\AddUsers zapisujemy' w folderze '/classes/MyApp/UsersAccounts/Actions/AddUsers/':

classes
|__MyApp
| |__UsersAccounts
| | |__Actions
| | |__AddUsers
| | |__Users.php

Jest to bardzo wygodne, proste i efektywne rozwiązanie - pozwala zachować strukturę umiejscowienia naszych plików z klasami odpowiadającą ich nazewnictwu w przestrzeni nazw.
Ponadto jest to pomocne również dla samego programisty, który "z automatu" już wie, gdzie należy szukać definicji danej klasy. Rozwiązanie takie stosuje m.in. framework Symfony.

Wykorzystajmy więc teraz funkcję '__autoload()' do zautomatyzowania sobie procesu dołączania naszych klas.
Na początek prześledżmy jak wygląda taki standardowy '__autoload()' dla zwykłych klas:

[code]
<?php
function __autoload($class_name)
{
require_once('classes/' . $class_name. '.php');
}
?>
[/code]

Usprawnijmy więc jego działanie, tak aby podążał za hierarchią naszej przestrzeni nazw w folderach:
[code]
<?php
function __autoload($class_name)
{
$path_to_class = 'classes/' . str_replace('\\', DIRECTORY_SEPARATOR, $class_name) . '.php';
require_once($path_to_class);
}
?>
[/code]

Jak widzimy, wszystkie backslashe są zamieniane na slashe rozdzielające nam ścieżkę do pliku z klasą.
I tak, np. wywołanie klasy 'Users' z przestrzeni nazw:
[code]MyApp\UsersAccounts\Actions\AddUsers[/code]
spowoduje, że funkcja __autoload() załaduje nam definicję klasy z pliku:
[code]/classes/MyApp/UsersAccounts/Actions/AddUsers/Users.php[/code]

Jak widać rozwiązanie jest proste i zarazem bardzo efektywne.
Ze swojej strony gorąco polecam stosowanie przestrzeni nazw nawet w mniejszych projektach, aby wyrobić sobie nawyk ich używania, gdyż przy większych projektach korzystanie z przestrzeni nazw jest wręcz konieczne.

Poza tym, w roku 2009 została po raz pierwszy obuplikowana konwencja o nazwie PSR-0, która jasno określa sposoby nazewnictwa przestrzeni nazw i odpowiedniego rozmieszczenia klas w folderach projektu. Konwencja ta ustala pewne reguły, dzięki którym nie występuje kolizja pomiędzy poszczególnymi aplikacjami, szczególnie tyczy to się funkcji __autoload().
Więcej o konwencji przeczytać możecie np. tutaj: http://phpedia.pl/wiki/Konwencja_nazewnictwa_PSR-0

No i to tyle, mam nadzieję, że opisałem cały mechanizm prosto i zrozumiale, zachęcam do własnoręcznego eksperymentowania.