Nasza Kohana http://nasza.kohanaphp.pl Sat, 02 Jan 2010 16:27:50 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 Widoków ciąg dalszy http://nasza.kohanaphp.pl/widokow-ciag-dalszy/ http://nasza.kohanaphp.pl/widokow-ciag-dalszy/#comments Sun, 29 Mar 2009 13:30:36 +0000 Zepco http://nasza.kohanaphp.pl/?p=359 Wiemy już jak utworzyć i wyświetlić prosty widok, pora przejść do bardziej złożonych zagadnień.

Fabryka widoków

Poza tworzeniem obiektów poprzez operator new istnieje alternatywna metoda. Jest to wzorzec projektowy nazywany fabryką abstrakcyjną. Więcej o tym wzorcu możesz przeczytać na Wikipedii, my natomiast skupimy się na tym co nam daje takie rozwiązanie w przypadku widoków.

Sam obiekt tworzymy wywołując statyczną metodę factory() z podobnymi parametrami co konstruktor:

1

$view = View::factory('home');

Zastanawiasz się pewnie czym to się różni od operatora new, bo przecież oba tworzą i zwracają obiekt klasy View. Oczywiście jest tak, z jedną różnicą. Wywołanie metody fabryki pozwala na łańcuchowanie (chaining) metod tej klasy bezpośrednio po jej utworzeniu.

Tradycyjną metodą:

1
2
3

$view = new View('home');
$view->set('title', 'Strona główna');
$view->bind('news', $news);

To samo z użyciem fabryki:

1
2
3

$view = View::factory('home')
	->set('title', 'Strona główna')
	->bind('news', $news);

Jak widzisz drugi zapis jest krótszy i bardziej czytelny.

Rozszerzone dodawanie zmiennych

Metoda set()

W poprzednim artykule zmienne lokalne przekazywaliśmy w poniższy sposób:

1

$view->title = 'Witaj!';

Podobne działanie posiada metoda set(), której zapis jest następujący:

1
2
3
4

$view->set('title', 'Witaj!');
// lub
$msg = 'Witaj!';
$view->set('title', $msg);

Jako pierwszy parametr podajemy nazwę zmiennej, której będziemy używać wewnątrz widoku, natomiast drugi parametr jest jej wartością przekazaną bezpośrednio bądź poprzez zmienną.

Metoda set_global()

Jak sama nazwa wskazuje, widok otrzymuje zmienną o zasięgu globalnym, przez co może być wykorzystywana zarówno w widoku głównym jednocześnie poprzez jego podwidoki.

1

$view->set_global('zmienna_widoku', $zmienna);

Więcej na temat zasięgu zmiennych przeczytasz w dalszej części artykułu.

Metoda bind()

Podobnie jak metoda set, bind działa w obrębie widoku, w którym został wywołany. Różnica polega jednak na tym, że zamiast wartości, przekazywana jest referencja do zmiennej. Co to oznacza w praktyce? Spójrz na poniższy przykład:

1
2
3
4
5
6
7

$sample_var = 10;
$view = View::factory('sample')
	->set('sample_set', $sample_var)
	->bind('sample_bind', $sample_var);
$sample_var = 20;
$view->render(true);
$sample_var = 30;

Widok:

1
2

Set = <?php echo $sample_set ?><br />
Bind = <?php echo $sample_bind ?>

Wynikiem powyższego będzie:

Set = 10
Bind = 20

W obu przypadkach przekazana została zmienna $sample_var, której wartość początkowa wynosi 10. Metoda set przekazała aktualną w danym momencie wartość zmiennej $sample_var i na tym skończyła się jej rola. Bind natomiast dała wskazanie na samą zmienną, co oznacza, że wszystkie operacje wykonane na $sample_var po przypisaniu jej do widoku ale przed wywołaniem metody render zostaną uwzględnione a wyświetlona będzie ostatnia zmiana. Można to wykorzystać na przykład w przypadku gdy zmienna jeszcze nie została zainicjowana.

1
2

$view->bind('sample_bind', $sample_var);
$sample_var = 20;

Widoki, podwidoki

Większość witryn składa się z elementów, które powtarzają się na każdej z podstron: nagłówek z logo, menu, stopka. Natomiast zmianom ulega tylko środkowa część prezentacji. Aby uniknąć ciągłego przepisywania tej samej zawartości do wszystkich widoków, możliwe jest stworzenie widoku głównego, szablonowego, do którego jako zmienna przekazywany jest kolejny widok. Zobrazuję to na przykładowym kodzie:

1
2
3

$view = new View('template');
$view->content = new View('home');
$view->render(true);

Można to również zapisać następująco:

1
2
3
4

$view = new View('template');
$home = new View('home');
$view->content = $home;
$view->render(true);

Pamiętaj jednak, że metodę render stosujemy tylko dla widoku bazowego, który jest najwyżej w hierarchii, pozostałe będą przetwarzane automatyczne.

Przykładowe pliki widoków wyglądają następująco:

1
2
3
4
5
6

<!-- application/views/template.php -->
<html>
<body>
	<?php echo $content ?>
</body>
</html>
1
2

<!-- application/views/home.php -->
Witaj, jestem Kohany(m) widokiem!

Efektem powyższych operacji będzie następujący kod html postaci:

1
2
3
4
5
6
7

<!-- application/views/template.php -->
<html>
<body>
	<!-- application/views/home.php -->
	Witaj, jestem Kohany(m) widokiem!
</body>
</html>

Co w oknie przeglądarki przełoży się na napis znany już z poprzedniej części kursu:

Witaj, jestem Kohany(m) widokiem!

Zasięg zmiennych

Lokalne

Zmienna ustawiona poprzez metodę set() bądź poprzez bezpośrednie przypisanie zmiennej do obiektu działa tylko w obrębie danego widoku i nie jest widoczny poza niego. Czyli jeśli utworzymy dwa widoki, np. widok1 oraz widok2 i w obu przypiszemy zmienną o tej samej nazwie, np. $zmienna, to będą to dwie odseparowane od siebie wartości.

1
2
3
4
5
6
7

$view1 = View::factory('widok1')
	->set('zmienna', 'pierwszy')
	->render(true);
 
$view2 = View::factory('widok2')
	->set('zmienna', 'drugi')
	->render(true);

Globalne

W przypadku użycia metody set_global() zmienna ustawiona będzie dostępna w każdym widoku.
Przykładowo mamy w kontrolerze widok $view i dla niego przypisaną zmienną globalną $test_var

1
2
3
4
5

$view = View::factory('view_test')
	->set_global('test_var', 'Test!')
	->set('test1', View::factory('test1'))
	->set('test2', View::factory('test2'))
	->render(TRUE);

Oraz widoki:

1
2
3
4

<!-- application/views/view_test.php -->
	<?php echo $test_var ?><br />	<!-- wyświetla zmienną w widoku głównym -->
	<?php echo $test1 ?><br />	<!-- wyświetla podwidok test1 -->
	<?php echo $test2 ?><br />	<!-- wyświetla podwidok test2 -->
1
2

<!-- application/views/test1.php -->
<?php echo $test_var ?>
1
2

<!-- application/views/test2.php -->
<?php echo $test_var ?>

Efektem tych poleceń jest wyświetlenie 3 razy tej samej zmiennej $test_var.

Test!
Test!
Test!

Dostęp poprzez $this

Widoki w Kohanie są tak skonstruowane, że zawierają się w tej samej przestrzeni nazw co kontroler je wykonujący. Daje to nam dostęp do pól i metod tego kontrolera poprzez zmienną $this.

Przykładowo mamy kontroler test:

1
2
3
4
5
6
7
8

class Test_Controller extends Controller {
	public $sample_var = 'Hello!';
 
	public function index()
	{
		$view = View::factory('test')->render(true);
	}
}

Oraz widok test.php:

1

Zmienna sample_var = <?php echo $this->sample_var ?>

Wykonanie powyższego kontrolera da nam wynik:

Zmienna sample var = Hello!

Ta metoda dostępu do danych nie jest zalecani można ją powodzeniem zastąpić wcześniej wymienionymi metodami: set(), set_global(), bind().

Pozostałe operacje na widokach

Metoda set_filename()

Metoda set_filename() pozwala na przypisanie pliku do widoku w przypadku gdy nie został on podany w momencie tworzenia obiektu, bądź zmianę wcześniej przypisanej nazwy.

1
2
3
4
5

$view = View::factory()
	->set('title', 'Witaj!');
...
$view->set_filename('template');
$view->render(TRUE);
1
2
3
4
5

$view = View::factory('template')
	->set('title', 'Witaj!');
...
$view->set_filename('another_template');
$view->render(TRUE);

Wszystkie zmienne przypisane do widoku będą użyte w ostatnio przypisanej nazwie pliku i ten plik widoku zostanie wyświetlony.

Z powyższej metody można korzystać na przykład w przypadku sprawdzania czy jest ktoś zalogowany. Jeśli warunek będzie spełniony zostanie utworzony widok z interesującymi nas danymi. W przeciwnym wypadku nazwa pliku zostanie zmieniona na widok z komunikatem błędu.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$view = View::factory('template');
// sprawdź czy użytkownik jest zalogowany
if ($logged_in)
// jeśli tak, wykonaj operacje na widoku
{
	$view->set('title', 'Tajne dane');
	...
}
else
// jeśli nie, pokaż komunikat błędu
{
	$view->set_filename('not_logged');
}
$view->render(TRUE);

Metoda is_set()

Jeśli nie masz pewności czy dana zmienna została przypisana już do widoku, to można to sprawdzić właśnie za pomocą metody is_set(). Wystarczy podać jako parametr nazwę zmiennej a funkcja sprawdzi czy jest zmienną lokalną danego widoku bądź też globalną dla wszystkich. Jako wynik otrzymasz wartość logiczną.

1
2
3
4
5
6
7
8
9
10
11

$view = View::factory('sample_view')
	->set('sample_var', 'Kohana');
 
if ($view->is_set('sample_var'))
{
	echo 'Zmienna istnieje!';
}
else
{
	echo 'Zmienna nie istnieje!';
}

Ponieważ wcześniej zadeklarowaliśmy zmienną sample_var, to metoda is_set() zwróci wartość logiczną true, w wyniku czego otrzymamy komunikat:

Zmienna istnieje!

Możliwe jest też sprawdzenie kilku zmiennych na raz, wtedy jako parametr podajemy tablicę z ich nazwami

1
2
3
4

$view = View::factory('sample_view')
	->set('sample_var', 'Kohana');
 
echo Kohana::debug($view->is_set(array('sample_var', 'another_var')));

Wynik:

(array) Array
(
[sample_var] => 1
[another_var] =>
)

Jak widać powyżej metoda is_set() zwróci tablicę, gdzie kluczem jest nazwa zmiennej, któremu przypisana będzie wartość logiczna mówiąca o istnieniu danej zmiennej.

]]> http://nasza.kohanaphp.pl/widokow-ciag-dalszy/feed/ 0 Widok http://nasza.kohanaphp.pl/widok/ http://nasza.kohanaphp.pl/widok/#comments Mon, 23 Mar 2009 00:09:13 +0000 Zepco http://nasza.kohanaphp.pl/?p=288 Jak zapewne już wiesz, według wzorca MVC nie wolno wyświetlać danych bezpośrednio w kontrolerze. Ta działka należy do widoków (views), którymi zajmiemy się w tej części artykułu.

Tworzenie prostego widoku

Za operacje na widokach odpowiedzialna jest klasa View, zatem, aby powstał widok wystarczy stworzyć obiekt tej klasy.

$widok = new View;

Konstruktor View może przyjmować do trzech parametrów:

  1. nazwa pliku – nazwa pliku widoku bez rozszerzenia (patrz parametr rozszerzenie), należy pamiętać, że nie może ona zawierać rozszerzenia pliku;
  2. dane – zmienne w formie tablicy, które będą użyte w widoku;
  3. rozszerzenie – standardowym rozszerzeniem plików widoków jest .php, ale parametr ten pozwala na wczytanie pliku o innym rozszerzeniu, np. .tpl, .html etc..

W związku z powyższym istnieją jeszcze 4 warianty na utworzenie widoku:

  1. sam widok o nazwie pliku moj_widok.php 
    $view = new View('moj_widok');
  2. widok z przekazanymi danymi z tablicy $dane

    $view = new View('moj_widok', $dane);
  3. widok o nazwie pliku moj_widok.html z danymi

    $view = new View('moj_widok', $dane, 'html');
  4. widok o nazwie pliku moj_widok.html bez danych

    $view = new View('moj_widok', null, 'html');

Gdzie znajdują się pliki widoku?

Pliki widoku znajdują się w katalogu views. Zgodnie ze wspomnianym wcześniej kaskadowym systemem plików może to być system/views, models/[nazwa modelu]/views, application/views.

W przypadku naszej aplikacji będziemy umieszczać je w ostatnim z wymienionych katalogów, czyli application/views. Widoki mogą być także zawarte w podkatalogach katalogu views, wtedy przy tworzeniu obiektu należy podać względną ścieżkę do pliku, np.:

$widok = new View('podkatalog/moj_widok');

Zatem utwórzmy plik home.php w katalogu application/views. Dla przykładu umieścimy tam zmodyfikowany tekst kontrolera z poprzedniego wpisu.

Witam - jestem Kohany(m) widokiem! :)

Wyświetlenie widoku

No dobrze, wiemy jak utworzyć widok, wiemy gdzie go umieścić, ale żeby zobaczyć efekt należy go jeszcze wyświetlić.

Do tego celu służy metoda render().

Metoda ta przyjmuje dwa parametry. Drugi chwilowo możemy pominąć :) . Pierwszy z nich natomiast jest wartością logiczną decydującą o tym czy wysłać bezpośrednio zawartość widoku do przeglądarki, np.

$view->render(true);

Spowoduje wyświetlenie widoku bez dodatkowych zabiegów, natomiast taki zapis

$output = $view->render();  // lub $output = $view->render(false)
echo $output // dopiero tutaj wyświetlamy widok

spowoduje przekazanie zawartości widoku do zmiennej $output ale nie wysyła go do przeglądarki, dopiero później (np. za pomocą funkcji echo) możemy ja wyświetlić.

Jak to w praktyce będzie wyglądać? Posłużymy się wcześniej utworzonym kontrolerem home.

1
2
3
4
5
6
7
8
9

<?php defined('SYSPATH') OR die('No direct access allowed.');
class Home_Controller extends Controller {
 
        public function index()
        {
		$view = new View('home');
		$view->render(true);
        }
}

Powyższy kod spowoduje wyświetlenie napisu z naszego widoku, czyli:

Witam – jestem Kohany(m) widokiem! :)

Dodanie zmiennych

Widok już mamy, pora by stał się bardziej dynamiczny. Przekażmy mu jakieś dane do wyświetlenia.
Dane do widoku przekazujemy tak, jakbyśmy chcieli zapisać jakąś wartość własności obiektu.

Na przykład, mamy widok $view i chcemy mu utworzyć zmienną $title o wartości „Witaj!”. Nic prostszego!

$view->title = 'Witaj!';

Podobnie można postąpić w przypadku tablic:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$view->articles = array(
	array(
		'title'		=> 'Pierwszy wpis',
		'content'	=> 'Lorem ipsum dolor sit amet, consectetur adipiscing elit.',
		'author'	=> 'Kohana',
		'date' 		=> '22-03-2009',
	),
	array(
		'title'		=> 'Kolejny wpis',
		'content'	=> 'Nulla et massa vitae erat placerat consequat.',
		'author'	=> 'Kohana',
		'date' 		=> '23-03-2009',
	),
);

Wyświetlanie zmiennych

Widoki w Kohanie są zwykłymi plikami PHP, także wyświetlanie zmiennych nie wymaga specjalnych zabiegów czy też dodatkowych znaczników.
W przypadku powyższych zmiennych będzie to wyglądało następująco:

1
2
3
4
5
6
7
8
9
10

<?php echo $title ?>
 
<h1>Artykuły</h1>
 
<?php foreach($articles as $article) { ?>
	<h2><?php echo $article['title'] ?></h2>
	<h3>Autor: <?php echo $article['author'] ?></h3>
	<h4>Data: <?php echo $article['date'] ?></h4>
	<p><?php echo $article['content'] ?></p>
<?php } ?>

Czego efektem będzie poniższy wydruk:

Witaj!

Artykuły

Pierwszy wpis

Autor: Kohana

Data: 22-03-2009

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Kolejny wpis

Autor: Kohana

Data: 23-03-2009

Nulla et massa vitae erat placerat consequat.

]]> http://nasza.kohanaphp.pl/widok/feed/ 0 Startujemy! Pierwszy kontroler http://nasza.kohanaphp.pl/startujemy-pierwszy-kontroler/ http://nasza.kohanaphp.pl/startujemy-pierwszy-kontroler/#comments Sun, 22 Feb 2009 09:50:32 +0000 Insert http://nasza.kohanaphp.pl/?p=130 Po skonfigurowaniu aplikacji czas, żeby efekty naszej pracy w końcu zaczęły być widoczne. Czas na pierwszy kontroler!

Zaczynamy

Aby napisać swój pierwszy kontroler należy wejść do katalogu /application/controllers/. Tam, jak pisaliśmy już w rozdziale Struktura i nazewnictwo znajdują się wszystkie kontrolery naszej aplikacji.

Obecnie z pewnością widzisz 2 pliki, welcome.php oraz examples.php. Są to kontrolery predefiniowane przez zespół rozwojowy Kohany po to, abyś mógł sam lepiej zrozumieć i rozeznać się w szkielecie aplikacji. Ten pierwszy służy do wyświetlenia strony startowej, którą widzisz bezpośrednio po zainstalowaniu Kohany (i usunięciu pliku install.php z głównego katalogu). Drugi zaś odpowiada za wyświetlenie strony z przykładami (jest ona dostępna pod adresem http://localhost/kohana/index.php/examples, jeżeli instalowałeś Kohanę w nadrzędnej ścieżce swojego serwera HTTP, w podkatalogu /kohana). Oba te kontrolery nie będą nam potrzebne, ale warto je zachować na później (być może jakieś przykładowe rozwiązanie okaże się w przyszłości pomocne).

Standardy tworzenia kontrolerów

Z przytoczonego wcześniej rozdziału Struktura i nazewnictwo musisz zapamiętać, że:

  • nazwa pliku musi być zapisana małymi literami, np. artykuly.php;
  • nazwa kontrolera musi się pokrywać z nazwą pliku , dodatkowo kończy się sufiksem _Controller (np. Artykuly_Controller). Pierwsze litery wyrazów są duże, pozostałe małe;
  • musi dziedziczyć po klasie Controller bądź jednym z jego potomków;
  • standardowo wywoływana jest funkcja index (jeśli nie podano inaczej).

Napiszmy coś wreszcie!

Pierwszy kontroler będzie odpowiadał za wyświetlenie strony głównej naszego bloga. Jeżeli czytałeś rozdział Instalacja i konfiguracja wiesz już, że istnieje taki plik konfiguracyjny jak routes.php, a w nim przechowywana jest linijka dotycząca kontrolera domyślnego (czyli nazwy kontrolera, który zostanie wywołany przy bezpośrednim otwarciu strony głównej naszej aplikacji w przeglądarce internetowej). Dla naszych potrzeb głównym kontrolerem, który będzie wczytywany domyślnie jako pierwszy będzie kontroler o nazwie home. Dlatego też należy dokonać zmiany wpisu, z postaci obecnej:

1

$config['_default'] = 'welcome';

Do postaci:

1

$config['_default'] = 'home';

Teraz, po odświeżeniu strony zobaczymy błąd. Jest on jednak w pełni uzasadniony – nie ma kontrolera o nazwie home, którego przy odświeżeniu witryny szukał przed chwilą skonfigurowany przez Ciebie router. Jeżeli go nie ma – stwórzmy go!

Kontroler strony głównej – “home”

Tworzymy zatem kontroler o nazwie pliku home.php, który ma poniższą zawartość:

1
2
3
4
5
6
7
8
9

<?php defined('SYSPATH') OR die('No direct access allowed.');
 
class Home_Controller extends Controller {
 
	public function index()
	{
		echo 'Witam - jestem Kohany(m) kontrolerem! :)';
	}
}

Odśwież teraz stronę… Tak – kontroler zadziałał. W Kohanie kontrolery mapowane są jak podstrony – dlatego ten sam kontroler zadziała, kiedy wpiszesz http://localhost/kohana/index.php/home. Teraz nie musiałeś tego robić, ponieważ ustawiłeś router, który przy domyślnym wywołaniu ($config['_default'] – patrz lekko powyżej) ma za zadanie wywołać kontroler home.

Akcja kontrolera, jej sposób prezentacji i przyjmowanie parametrów

Zmodyfikuj kontroler home.php do poniższej postaci:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<?php defined('SYSPATH') OR die('No direct access allowed.');
 
class Home_Controller extends Controller {
 
	public function index()
	{
		echo 'Witam - jestem Kohany(m) kontrolerem! :)';
	}
 
	public function podstrona($parametr1, $parametr2)
	{
		echo 'Witam - jestem kontrolerem podstrony.
			<br />Przyjąłem 2 parametry:
			<ul>
				<li>Pierwszy: '.$parametr1.'</li>
				<li>Drugi: '.$parametr2.'</li>
			</ul>';
	}
}

Co zrobiliśmy? Otóż dodaliśmy funkcję kontrolera (w nomenklaturze MVC częściej na funkcję w kontrolerze mówi się “akcja”), która ma za zadanie wyświetlić prosty tekst oraz zawartość dwóch przyjmowanych przez siebie parametrów. Parametry te przyjmowane są z URL’a (definiowane jako kolejne segmenty adresu). Jak więc obecnie wygląda URL tej akcji? Zobaczmy: http://localhost/kohana/index.php/home/podstrona/pierwszy_parametr/drugi_param.

Epilog

Nie przejmuj się nieładnym URL’em. Niedługo poznasz technikę “wycinania” index.php z adresu Twojej strony, dzięki czemu uzyskasz bardziej przejrzystą i elegancką strukturę adresu.

Wzorzec projektowy MVC nie pozwala nam na to, abyśmy w kontrolerze wykonywali funkcję echo (nigdy nie należy tego robić – niniejszy kod jest tylko tymczasowym przykładem, natomiast do wyświetlania tego typu napisów służą widoki). Dlatego też dalszą część tworzenia naszego prostego systemu blogowego będziemy prowadzić w dalszych rozdziałach. Tam wykorzystamy widoki, a później modele. Tak, by kod naszego bloga był w pełni zgodnym ze wszystkimi najważniejszymi standardami, zasadami i dyrektywami inżynierii oprogramowania.

Kod źródłowy, użyty do tego artykułu, zajduje się tutaj.

]]> http://nasza.kohanaphp.pl/startujemy-pierwszy-kontroler/feed/ 0 Instalacja i konfiguracja http://nasza.kohanaphp.pl/instalacja-i-konfiguracja/ http://nasza.kohanaphp.pl/instalacja-i-konfiguracja/#comments Thu, 19 Feb 2009 20:02:06 +0000 mck http://nasza.kohanaphp.pl/?p=94 Czas na 3 krok naszego kursu. Zajmiemy się instalacją i podstawową konfiguracją Kohany. Nie są to zbyt skomplikowane czynności, ale warto wiedzieć o kilku szczegółach by uniknąć błędów.

Gdzie rośnie Kohana?

Po najnowszą paczkę Kohany udajemy się na oficjalną stronę do działu Download, gdzie możemy wybrać interesujące nas składniki.

Do dyspozycji mamy 5 modułów:

  • Archive – do zarządzania archiwami zip, tar, gzip i bzip
  • Auth – do uwierzytaelniania i zarządzania użytkownikami (używa biblioteki ORM)
  • Gmaps – do szybkich i bezbolesnych zabaw z Google Maps
  • Kodoc – do generowania dokumentacji
  • Payment – do obsługi płatności (z istotniejszych jest tu PayPal, natomiast brak jakiegokolwiek wsparcia polskich systemów płatności)

Mamy też narzędzia Markdown (do obsługi i konwersji znaczników zgodnie z przyjętymi zasadami) i SwiftMailer (do zaawansowanej obsługi maili), a także spory wybór języków.

W naszych przykładach będziemy korzystać z modułu Auth, narzędzia SwiftMailer i języka polskiego.

Instalacja

W przypadku Kohany jest to czynność dziecinnie prosta. Wystarczy rozpakować pobraną paczkę do wybranego katalogu (dla nas będzie to katalog o finezyjnej nazwie “kohana”). Oto jak powinna wyglądać jego zawartość:

Rys. 3.1. Zawartość głównego folderu

Po uprzednim zapoznaniu się z licencją możemy się jej pozbyć, tak samo jak loga Kohany, gdyż w praktyce się nam nie przydadzą.

Plik "install.php" jest absolutną nowością (przed wersją 2.3 nie było takich frykasów). Wprawdzie jest to najzwyklejszy test sprawdzający czy posiadamy wszystkie niezbędne do uruchomienia Kohany składniki, ale cieszy. Oczywiście po pomyślnym zakończeniu testu zostaniemy poproszeni o jego usunięcie lub zmianę nazwy (kolejne testy możemy sobie darować, więc może podzielić los licencji i loga).

.htaccess, czyli przyjazne linki i nie tylko

W katalogu z Kohaną znajdziemy plik "example.htaccess", który w zasadzie jest gotowy do użycia (oczywiście po zmianie nazwy na ".htaccess" i usunięciu z niego wiersza z “RewriteBase /kohana/” lub jego zmianie na “RewriteBase /“).

Podstawowa konfiguracja

Wszystkie pliki odpowiedzialne za konfiguracje znajdują się w katalogu "application/config/", który na początku, choć wygląda skromnie, ma wszystko czego nam potrzeba, czyli główny plik konfiguracyjny "config.php".

Z najciekawszych rzeczy jakie można w nim skonfigurować warto wymienić:

  • site_domain – główna ścieżka do strony
  • index_page – nazwa pliku odpowiedzialnego za działanie aplikacji. Domyślnie jest to "index.php", ale jeśli chcemy mieć ładne linki, to zmieniamy jego wartość na pustą
  • url_suffix – rozszerzenie plików dodawane do generowanych adresów. Domyślnie puste, ale możemy mu nadać dowolną wartość, np.: ".html"
  • internal_cache – okres czasu (w sekundach) przez jaki ma być cache’owana konfiguracja Kohany
  • enable_hooks – zarządzanie hakami (nimi zajmiemy się w niedalekiej przyszłości). Możemy je wyłączyć (wartość "FALSE"), włączyć wszystkie ("TRUE") lub włączyć wybrane (tablica z nazwami haków)
  • modules – zarządzanie modułami. Wystarczy odkomentować wybrane moduły lub dodać swoje własne (oczywiście wszystkie muszą się znajdować w katalogu "modules/")

Co jeszcze można skonfigurować?

Wszystko, serio :)

W katalogu "system/config/" znajdują się wszystkie dostępne pliki konfiguracyjne używane przez Kohanę. Z poprzedniego artykułu wiecie, że najważniejsze są pliki z katalogu "application/", następnie z modułów, a na końcu z katalogu "system/", więc zamiast grzebać w domyślnych plikach konfiguracyjnych kopiujemy wybrane do katalogu "application/config/" i tam je można edytować. Zmiany w katalogu "system/*" są niewskazane.

Oczywiście Kohana nie ogranicza nas tylko do używania jej plików konfiguracyjnych, ale pozwala nam na tworzenie własnych (więcej szczegółów trochę niżej).

Routing, czyli skąd i dokąd

Kohana zapewnia nam następujące mapowanie linków:

1

naszastrona.pl/klasa/funkcja/parametr1/parametr2/.../parametr-n

gdzie klasa to nazwa kontrolera, funkcja to nazwa wybranej funkcji, a kolejne segmenty to przekazywane parametry. Dzięki routingowi możemy otrzymać niemal dowolne linki.

Za konfigurację routingu odpowiada plik "routes.php", który początkowo zawiera jeden wpis:

1

$config['_default'] = 'welcome';

czyli jako domyślny ustawiony jest kontroler “welcome”.

Oczywiście możemy definiować własne trasy:

1
2
3
4
5
6
7
8

// dla adresu 'naszastrona.pl/o_firmie' uruchamiamy domyślną metodę 'index' z kontrolera 'info'
$config['o_firmie'] = 'info';
 
// dla adresu 'naszastrona.pl/kontakt' uruchamiamy metodę 'kontakt' z kontrolera 'info'
$config['kontakt'] = 'info/kontakt';
 
// dla adresu 'naszastrona.pl/produkt/13' uruchamiamy z parametrem '13' metodę 'pokaz' z kontrolera 'produkty'
$config['produkt/([0-9]+)'] = 'produkty/pokaz/$1';

Najważniejsze pliki konfiguracyjne

database.php – ustawienia połączenia z bazą danych. Najważniejsze z nich:

  • connection['user'] – nazwa użytkownika bazy
  • connection['pass'] – hasło użytkownika bazy
  • connection['host'] – host
  • connection['database'] – nazwa bazy
  • connection['character_set'] – system kodowania znaków

cookie.php – ustawienia ciastek. Najważniejsze z nich:

  • domain – domena, dla której dostępne są ciastka. Domyślnie puste – każda strona może odczytać zawartość tych ciastek
  • expire – długość życia ciastka (w sekundach). Domyślnie 0 – do zamknięcia przeglądarki

locale.php – ustawienia lokalizacji:

  • language – język strony. Pierwszym elementem tablicy musi być nazwa katalogu (i równocześnie symbolem języka w i18n) z plikami językowymi. Dla naszych przykładów będzie to: pl_PL. Kolejne elementy są alternatywą dla systemów nie obsługujących i18n. Więcej na: php.net/setlocale
  • timezone – strefa czasowa. Domyślnie pusta – używamy strefy czasowej serwera. Więcej na: php.net/timezones

pagination.php – ustawienia stronicowania. Najważniejsze z nich:

  • uri_segment – numer lub nazwa segmentu z numerem aktualnej strony
  • items_per_page – liczba elementów wyświetlanych na jednej stronie

session.php – ustawienia sesji. Najważniejsze z nich:

  • driver – sterownik sesji. Do wyboru: “cookie”, “database”, “native” lub “cache”
  • name – nazwa sesji
  • validate – tablica parametrów do walidacji. Do wyboru: “user_agent”, “ip_address” i “expiration”
  • expiration – długość życia sesji (w sekundach)

Własne pliki konfiguracyjne

Jak już wcześniej wspomniałem Kohana daje nam możliwość używania własnych plików konfiguracyjnych. Dla przykładu stwórzmy w katalogu "application/config/" plik "konfiguracja.php":

1
2

$config['parametr1'] = 'wartosc1';
$config['parametr2'] = 'wartosc2';

Możemy wczytać do tablicy cały plik:

1

$konfiguracja = Kohana::config_load('konfiguracja');

lub odczytać wybrany parametr:

1

$parametr = Kohana::config('konfiguracja.parametr2');
]]> http://nasza.kohanaphp.pl/instalacja-i-konfiguracja/feed/ 0 Struktura i nazewnictwo http://nasza.kohanaphp.pl/struktura-kohany/ http://nasza.kohanaphp.pl/struktura-kohany/#comments Thu, 19 Feb 2009 19:51:04 +0000 Zepco http://nasza.kohanaphp.pl/?p=36 Struktura katalogów

Zanim przejdziemy do utworzenia pierwszego kontrolera, zapoznaj się ze strukturą katalogów i elementami jakie posiada Kohana.

Całość dzieli się na 3 katalogi:

  • system – tu znajduje się „serce” naszego frameworka, w tym główny rdzeń (core) oraz inne elementy, których krótki opis znajduje się poniżej;
  • modules – zawiera kod (biblioteki, modele, widoki itp.), który jest na tyle uniwersalny, że może być wykorzystywany w innych projektach (np. obsługa użytkowników);
  • application – ten katalog będzie nas interesował najbardziej. To w nim przechowywane są wszystkie pliki związane z naszą aplikacją.
Rys. 2.1. Struktura katalogów

Nasze skrypty uruchamiane są poprzez plik index.php. To on ładuje podstawowe klasy Kohany, które później decydują który z elementów naszej aplikacji ma być obsłużony.

Elementy Kohany

Jak zapewne zauważyłeś, we wszystkich 3 katalogach jest podobna struktura podkatalogów:

  • config – jak sama nazwa wskazuje zawiera pliki z konfiguracją aplikacji, bibliotek czy też poszczególnych modułów. Więcej informacji na temat konfiguracji znajdziesz w następnym artykule;
  • helpers – zawiera klasy podobne do bibliotek (libraries) z tym wyjątkiem, że posiadają metody statyczne, przez co nie potrzebna jest instancja klasy, żeby użyć którejś z jej funkcji;
  • hooks – czasem istnieje potrzeba uruchomienia kawałka kodu poza ramami działania kontrolera (np. przed jego wywołaniem lub w momencie wysłania nagłówków). Do tego właśnie służą “haki”;
  • i18n (skrót od internationalization) – katalog ten zawiera pliki językowe z komunikatami i tekstami, które chcemy aby były przetłumaczone na naszej stronie. Poza zdefiniowanymi standardowo można utworzyć własne;
  • libraries – katalog z naszymi bibliotekami wykorzystywanymi w aplikacji;
  • vendor – znalazłeś w internecie jakąś bibliotekę, której chciałbyś użyć w Kohanie? To miejsce jest właśnie dla niej. W tym katalogu przechowywane są klasy zewnętrznych bibliotek, zaadoptowane do współpracy z naszym frameworkiem;
  • controllers, models, views – elementy te pokrótce były opisane wcześniej, więc nie ma sensu się nad nimi rozwodzić. W następnych wpisach zajmiemy się dokładniej ich tworzeniem i zastosowaniem w aplikacji.

Kaskadowy system plików

Charakterystyczną rzeczą, wartą uwagi w Kohanie jest kaskadowy system plików. Takie rozwiązanie pozwala na nadpisanie plików bez konieczności ich modyfikacji czy usuwania.  Jeśli chcemy otworzyć jakiś plik będzie on przeszukiwany w katalogach w kolejności application -> modules -> system. Jeśli plik nie znajdzie się w żadnym z nich, to zostanie wyświetlony komunikat błędu (w przypadku braku kontrolera błąd 404). Podkatalogi w modules są przeglądane w kolejności ich dodania w pliku konfiguracyjnym config.php (o konfiguracji powiemy w następnym artykule). Spójrz na poniższy rysunek.

Rys. 2.2. Kaskadowy system plików (autor Geert De Deckere)

W katalogu system/views mamy widok layout.php, który posiada szkielet strony. Ale my chcemy mieć własny szkielet z własnym wyglądem. Dlatego też tworzymy plik o tej samej nazwie w katalogu naszej aplikacji (application/views). Dzięki temu Kohana otrzymując polecenie odnalezienia widoku, szuka go najpierw w naszym katalogu. W tym przypadku znalazł go od razu, więc pomija pozostałe lokalizacje. Dla widoku products.php, który znajduje się aż w trzech miejscach (module a, module b oraz system), wygrywa katalog module a, ponieważ był najwyżej w hierarchi.

Rozwiązanie to jest bardzo użyteczne w przypadku konfiguracji. W zasadzie nie powinieneś nic zmieniać w katalogu system, ponieważ w przypadku aktualizacji Kohany stracisz wszystkie zmiany, a po pewnym czasie raczej nie będziesz pamiętać co i gdzie zmieniłeś.  Zatem jeśli brakuje jakiegoś pliku, który istnieje w katalogu system/config, bądź w którymś z modułów, a który chcesz zmodyfikować, to skopiuj go do application/config i tam dopiero modyfikuj.

Standardy nazewnictwa

Aby Kohana wiedziała gdzie znaleźć elementy naszej aplikacji musimy zachować pewne standardy.

  • Kontrolery (controllers):

    • nazwa pliku musi być zapisana małymi literami, np. artykuly.php;
    • nazwa kontrolera musi się pokrywać z nazwą pliku , dodatkowo kończy się sufiksem _Controller (np. Artykuly_Controller). Pierwsze litery wyrazów są duże, pozostałe małe;
    • musi dziedziczyć po klasie Controller bądź jednym z jego potomków;
    • standardowo wywoływana jest funkcja index (jeśli nie podano inaczej).
  • Pomocniki (helpers):

    • nazwę pliku i klasy zapisujemy małymi literami.  Nazwa pliku pokrywa się z nazwą klasy (z wyjątkiem sufiksu _Core);
    • do nazw nowych klas dodajemy sufiks _Core, np. html_Core, tak aby w przyszłości możliwe było rozszerzenie funkcjonalności klasy.
  • Biblioteki (libraries):

    • nazwa pliku podobnie jak w przypadku pomocników pokrywa się z nazwą klasy (z wyjątkiem sufiksu _Core), ale musi zachować takie same wielkości liter jak nazwa klasy;
    • nazwa klasy zaczyna się od wielkiej litery, wielkość pozostałych liter zależy od programisty;
    • w przypadku nowych klas postępujemy analogicznie jak w pomocnikach.
  • Modele (models):

    • nazwy plików składają się z małych liter i mają taką samą nazwę jak klasa (bez sufiksu _Model);
    • nazwa modelu musi się pokrywać z nazwą pliku, dodatkowo kończy się sufiksem _Model (np. User_Model). Pierwsze litery wyrazów są duże, pozostałe małe;
    • nazwa modelu powinna być zapisana w liczbie pojedynczej (ważne w przypadku angielskich nazw i użycia ORM).
  • Widoki (views):

    • nazwy plików w tym przypadku mogą być dowolne, wielkość liter nie ma znaczenia, byleby przy wywołaniu widoku ją zachować. Musi być jedynie zakończona rozszerzeniem .php.
]]> http://nasza.kohanaphp.pl/struktura-kohany/feed/ 0 Wprowadzenie http://nasza.kohanaphp.pl/wprowadzenie/ http://nasza.kohanaphp.pl/wprowadzenie/#comments Thu, 19 Feb 2009 19:47:05 +0000 Zepco http://nasza.kohanaphp.pl/2008/12/25/14/ Kohana jest jednym z wielu frameworków stworzonych w języku PHP.

Jej korzenie sięgają innego frameworka o nazwie Code Igniter (CI). Ponieważ deweloperzy CI zapowiedzieli, że ich produkt nie będzie wspierał PHP w wersji 5, grupa programistów korzystających dotychczas z CI postanowiła utworzyć nowy projekt, idący z duchem czasu i wspierający coraz bardziej rozwijającą się obiektowość dla PHP. Tak powstała Kohana, początkowo bardzo podobna do CI, lecz w tej chwili utożsamia się tylko z jego ogólnymi ideami działania, ponieważ sam projekt jest w pełni samodzielny i jego rozwój biegnie własnym torem.

Co cechuje Kohanę?

  • Oparta o wzorzec MVC (o tym za chwilę);
  • Napisana w PHP 5, także jeśli jesteś osobą znającą ten język, to być może Kohana przypadnie ci do gustu;
  • W porównaniu z niektórymi kolosami typu Symfony, Mojavi itp. jest dość szybka;
  • Poza samym wzorcem MVC i ogólnymi zasadami konstrukcji Kohana daje dość ogromną swobodę w tworzeniu aplikacji.

Czym jest MVC?

Jak możemy wyczytać w Wikipedii, MVC jest wzorcem projektowym dzielącym aplikację na 3 części:

  • Model – jego zadaniem są operacje na danych. Najczęściej modele korzystają z baz danych, ale równie dobrze mogą odwoływać się do dokumentów będących na dysku czy też innych stron;
  • Widok – w wielu serwisach rolę widoku określa się jako oddzielenie kodu PHP od HTML, co jest oczywiście nieprawdą. Jednym słowem widok tworzy to, co użytkownik otrzymuje na wyjściu, w zależności od założeń działania aplikacji. Może to być reprezentacja danych pobranych z modelu – w formie tabeli – połączonych z interfejsem zapisanym jako kod HTML, czy też inny rodzaj pliku (PDF, XML);
  • Kontroler –  jest łącznikiem między modelem i widokiem. Jego zadaniem jest odbieranie żądań użytkownika, wysyłanie zapytania do modelu o konkretne dane, a po ich otrzymaniu odesłanie ich do widoku. Jednym słowem kontroluje on przebieg aplikacji.

Co nam daje taki podział?

Przede wszystkim model stanowi pewnego rodzaju czarną skrzynkę, o której wiemy tylko to, co z nią zrobić, żeby zwróciła interesujące nas dane. A to, w jaki sposób to zrobi i z jakiego źródła danych skorzysta (plik, baza MySQL, PostgreSQL, XML itp.) nie będzie już nas interesować. Jego zadaniem będą tylko operacje na danych (odczytywanie, zapisywanie itp.) i nic poza tym.

Dajmy na to, że mamy dostawcę, którego prosimy o dostarczenie danego produktu (np. soku). Nie interesuje nas, czy weźmie go z hurtowni A czy z hurtowni B. Ważne, że otrzymamy to o co prosimy. Może być taka sytuacja, że dotychczas dostawca brał towar z hurtowni A, która z nieznanych przyczyn ogłosiła upadłość. Żeby wywiązać się z umowy, dostawca szuka innego źródła i znajduje hurtownię B, skąd dostarczy nam towar. My jako kupujący nie dostrzegamy różnicy, bo wszystko, o co poprosiliśmy zostało dostarczone, a kwestia “skąd” to już zmartwienie dostawcy.

Podobnie jest z modelem. Załóżmy, że do tej pory model pobierał dane z bazy MySQL, ale cały serwis musi być przeniesiony na PostgreSQL. Z zewnątrz nic się nie zmienia, nadal jest ten sam model i te same metody odwołujące się do niego, zmianie ulega tylko wnętrze modelu. Dzięki temu oszczędzamy wiele czasu i nerwów, bo nie musimy zmieniać wpisów odwołujących się, być może w kilkudziesięciu (czy nawet więcej) plikach do naszego modelu.

Podobnie sprawa może mieć się w przypadku widoku. Wyobraźmy sobie sytuację, że wszystkie dane pobrane z modelu były wyświetlane w formacie HTML, ale stworzyliśmy sobie program, który odwołuje się do naszej strony. Operuje on zaś na plikach XML. Co robimy? Przepisujemy naszą stronę na nowo? Nic podobnego – zmieniamy tylko widok tak, aby wyświetlał to co chcemy, czyli w tym przypadku XML. Pozostała część aplikacji (kontroler i modele) nie ulega zmianie.

Choć nic nie stoi na przeszkodzie, żeby tak dostosować kontroler, aby w zależności od tego czy żądanie wywodzi się od przeglądarki internetowej czy też z naszego programu, wybierał odpowiedni widok i wyświetlał go.

Jak widać rozwiązanie takie pozwala na zaoszczędzenie mnóstwa czasu. Ponadto możemy podzielić prace nad projektem na kilka osób, gdzie jedna np. może tworzyć model, inna widok, a jeszcze inna scalać oba te elementy tworząc kontroler.

To tyle tytułem wstępu. Kolejne części opisują budowę i zasadę tworzenia aplikacji z wykorzystaniem Kohany. A to wszystko na przykładzie tworzenia prostego blogu internetowego.

]]> http://nasza.kohanaphp.pl/wprowadzenie/feed/ 0