Text: {toc} p. Wiemy już jak wyświetlić statyczny tekst w naszej aplikacji. Przydałoby się teraz abyśmy mogli wyświetlać treści dynamicznie, aby móc je modyfikować bez ingerencji w kod. Aby otrzymać taką funkcjonalność musimy podłączyć nasz system do bazy danych. Na początek spróbujmy dodać do naszej strony menu w którym możemy włączać i wyłączać z bazy poszczególne zakładki. p. Po pierwsze musimy posiadać dostęp do jakiejś bazy danych. Załóżmy że mamy dostęp do bazy danych o następujących parametrach: * serwer: mojserwer.edu.pl * port: 3306 * login: moj_login * hasło: moje_haslo123 * nazwa bazy: mojapel_baza h3. Połączenie do bazy p. W pliku konfiguracyjnym musimy zarejestrować połączenie do tej bazy. Robimy to w następujący sposób: pre.. .... ap_page::setBase('default','mysql://moj_login:moje_haslo@mojserwer.edu.pl:3306/mojapel_baza/head_'); .... p. Pierwszy argument metody setBase to nazwa połączenia. Dzięki temu parametrowi możemy w systemie łączyć się do kilku różnych baz. Nazwy połączeń mogą być dowolne, jednak przynajmniej jedno powinno nazywać się default - oznacza to połączenie domyślne. Ostatni fragment @head_@ oznacza nagłówek wszystkich tabel jakich bedziemy używać we frameworku - umożliwia to łączenie frameworka z innymi aplikacjami php. Nagłówek jest całkowicie pomijany w klasach (nie uwzględniamy go tworząc nazwy pól i kluczy) h3. Klasa ap_db p. Za obsługę baz danych odpowiada klasa ap_db. Na chwilę obecną system nie ma zaimplementowanej obsługi innego typu bazy jak mySql, jednak w przyszłości będzie taką funkcjonalność posiadał. Możemy jednak przyjąć że obiektów tej klasy używa się zawsze tak samo, niezależnie od typu bazy. p. Klasa ma zaimplementowane następujące metody: * @query('zapytanie sql','nazwa_połączenia');@ * @fetch('nazwa_połączenia');@ * @insert('nazwa_tabeli','tablica_pól','nazwa_połączenia');@ * @update('nazwa_tabeli','nowe_wartości','warunek','nazwa_połączenia');@ * @delete('nazwa_tabeli','warunek','nazwa_połączenia');@ * @begin('nazwa_połączenia');@ * @commit('nazwa_połączenia');@ * @rollback('nazwa_połączenia');@ p. Omówimy teraz poszczególne metody: h5. query p. Metoda kieruje zapytanie do bazy. Standardowo jest używana do tworzenia zapytań @SELECT....@, możemy jednak jej użyć to wszelkiego typu zapytań. Nazwa_połączenia informuje nas do której bazy odnosi się zapytanie. Gdy parametr ten nie jest podany, zapytanie jest adresowane do bazy zdefiniowanej w połączeniu nazwanym default. Ten warunek odnosi się do wszystkich metod, więc nie będziemy go więcej podawać. h5. fetch p. Po wykonaniu querychcielibyśmy otrzymać jakieś wyniki. Umożliwia nam to funkcja fetch która kolejno zwraca rekordy będące wynikiem zapytania. Jeśli zwrócono już wszystkie rekordy, lub wynik zapytania jest pusty, metoda zwraca null. Wyniki są zwracane w postaci tablicy asocjacyjnej w której kluczem jest nazwa pola tabeli, a wartością zawartość pola w bazie. h5. insert p. Metoda dodaje do tabeli nazwa_tabeli nowy rekord i zwraca jego id(id to @PRIMARY KEY@). Dane do zapisania, czyli tablica_pól, powinna być w formie tablicy asocjacyjnej gdzie kluczem jest nazwa pola, a wartością dana jaką na tym polu chcemy zapisać. h5. update p. Uaktualnienie rekordu w tabeli. Wartości do zapisania powinny być w tablicy asocjacyjnej, natomiast warunek może być w postaci albo tablicy asocjacyjnej, albo tekstowej. p. __Przykład:__ pre.. // oba zapisy są równoważne $db->update('jakas_tabela',array('poleUpdate'=>'nowa_wartość'),array('klucz'=>'id_klucza')); $db->update('jakas_tabela',array('poleUpdate'=>'nowa_wartość'),'klucz = id_klucza'); p. Postać tekstowa warunku umożliwia nam wprowadzanie klauzul postaci @a > b, a in (a,b,c)@ itp. h5. delete p. Usuwa rekordy z bazy spełniające podany warunek. Postać warunku taka jak przy update h5. begin, commit, rollback p. Metody służące do zapewnienia transakcyjności. p. Przyjmuje się że bezpośrednie odwołania do bazy przez obiekty klasy @ap_db@ powinny znajdować się wyłącznie w managerach i obiektach (@ap_obj@), jednak nie jest błędem ich użycie w innych miejscach, zwłaszcza gdy chodzi o optymalizację. Może to jednak skutkować pogorszeniem czytelności programu i późniejszymi problemami przy rozbudowie lub zmianach w aplikacji. → {toc} p. Wiemy już jak wyświetlić statyczny tekst w naszej aplikacji. Przydałoby się teraz abyśmy mogli wyświetlać treści dynamicznie, aby móc je modyfikować bez ingerencji w kod. Aby otrzymać taką funkcjonalność musimy podłączyć nasz system do bazy danych. Na początek spróbujmy dodać do naszej strony menu w którym możemy włączać i wyłączać z bazy poszczególne zakładki. p. Po pierwsze musimy posiadać dostęp do jakiejś bazy danych. Załóżmy że mamy dostęp do bazy danych o następujących parametrach: * serwer: mojserwer.edu.pl * port: 3306 * login: moj_login * hasło: moje_haslo123 * nazwa bazy: mojapel_baza h3. Połączenie do bazy p. W pliku konfiguracyjnym musimy zarejestrować połączenie do tej bazy. Robimy to w następujący sposób: pre.. .... ap_page::setBase('default','mysql://moj_login:moje_haslo@mojserwer.edu.pl:3306/mojapel_baza/head_'); .... p. Pierwszy argument metody setBase to nazwa połączenia. Dzięki temu parametrowi możemy w systemie łączyć się do kilku różnych baz. Nazwy połączeń mogą być dowolne, jednak przynajmniej jedno powinno nazywać się default - oznacza to połączenie domyślne. Ostatni fragment @head_@ oznacza nagłówek wszystkich tabel jakich bedziemy używać we frameworku - umożliwia to łączenie frameworka z innymi aplikacjami php. Nagłówek jest całkowicie pomijany w klasach (nie uwzględniamy go tworząc nazwy pól i kluczy) h3. Klasa ap_db p. Za obsługę baz danych odpowiada klasa ap_db. Na chwilę obecną system nie ma zaimplementowanej obsługi innego typu bazy jak mySql, jednak w przyszłości będzie taką funkcjonalność posiadał. Możemy jednak przyjąć że obiektów tej klasy używa się zawsze tak samo, niezależnie od typu bazy. p. Klasa ma zaimplementowane następujące metody: * @query('zapytanie sql','nazwa_połączenia');@ * @fetch('nazwa_połączenia');@ * @insert('nazwa_tabeli','tablica_pól','nazwa_połączenia');@ * @update('nazwa_tabeli','nowe_wartości','warunek','nazwa_połączenia');@ * @delete('nazwa_tabeli','warunek','nazwa_połączenia');@ * @begin('nazwa_połączenia');@ * @commit('nazwa_połączenia');@ * @rollback('nazwa_połączenia');@ p. Omówimy teraz poszczególne metody: h5. query p. Metoda kieruje zapytanie do bazy. Standardowo jest używana do tworzenia zapytań @SELECT....@, możemy jednak jej użyć to wszelkiego typu zapytań. Nazwa_połączenia informuje nas do której bazy odnosi się zapytanie. Gdy parametr ten nie jest podany, zapytanie jest adresowane do bazy zdefiniowanej w połączeniu nazwanym default. Ten warunek odnosi się do wszystkich metod, więc nie będziemy go więcej podawać. h5. fetch p. Po wykonaniu querychcielibyśmy otrzymać jakieś wyniki. Umożliwia nam to funkcja fetch która kolejno zwraca rekordy będące wynikiem zapytania. Jeśli zwrócono już wszystkie rekordy, lub wynik zapytania jest pusty, metoda zwraca null. Wyniki są zwracane w postaci tablicy asocjacyjnej w której kluczem jest nazwa pola tabeli, a wartością zawartość pola w bazie. h5. insert p. Metoda dodaje do tabeli nazwa_tabeli nowy rekord i zwraca jego id(id to @PRIMARY KEY@). Dane do zapisania, czyli tablica_pól, powinna być w formie tablicy asocjacyjnej gdzie kluczem jest nazwa pola, a wartością dana jaką na tym polu chcemy zapisać. h5. update p. Uaktualnienie rekordu w tabeli. Wartości do zapisania powinny być w tablicy asocjacyjnej, natomiast warunek może być w postaci albo tablicy asocjacyjnej, albo tekstowej. p. __Przykład:__ pre.. // oba zapisy są równoważne $db->update('jakas_tabela',array('poleUpdate'=>'nowa_wartość'),array('klucz'=>'id_klucza')); $db->update('jakas_tabela',array('poleUpdate'=>'nowa_wartość'),'klucz = id_klucza'); p. Postać tekstowa warunku umożliwia nam wprowadzanie klauzul postaci @a > b, a in (a,b,c)@ itp. h5. delete p. Usuwa rekordy z bazy spełniające podany warunek. Postać warunku taka jak przy update h5. begin, commit, rollback p. Metody służące do zapewnienia transakcyjności. p. Przyjmuje się że bezpośrednie odwołania do bazy przez obiekty klasy @ap_db@ powinny znajdować się wyłącznie w managerach i obiektach (@ap_obj@), jednak nie jest błędem ich użycie w innych miejscach, zwłaszcza gdy chodzi o optymalizację. Może to jednak skutkować pogorszeniem czytelności programu i późniejszymi problemami przy rozbudowie lub zmianach w aplikacji. "<<< Widok":http://www.xp-dev.com/wiki/67486/Widok - "Pierwsze kroki >>>":http://www.xp-dev.com/wiki/67486/Pierwsze%20kroki