Text: {toc} h3. Zasady nazewnictwa p. Aby w pełni wykorzystać mechanizmy zaimplementowane we frameworku musimy przestrzegać kilku zasad: h5. Baza danych p. Tabele w bazie powinny być nazywane w formacie nazwa_tabeli. Każda z tabel powinna posiadać klucz @PRIMARY@ o nazwie @nazwaTabeliId@. Jest to bardzo ważne gdyż zachowując taki format obiekty frameworku są w stanie automatycznie rozpoznać klucz główny tabeli i zautomatyzować operacje na bazie. Jeśli nie zachowamy takiego formatu nazewnictwa tabel, operacje odczytu i zapisu do tabeli będziemy musieli definiować sami. h5. Klasy p. Nazwa każdej klasy powinna być w formacie moja_nazwa_klasy, a jej definicja powinna znajdować się w katalogu @system/moja/nazwa/klasy.php@. W przypadku gdy nie zachowamy takiego formatu będziemy musieli jawnie używać instrukcji include bądź require. h3. Typy obiektów p. Do tworzenia aplikacji w oparciu o framework APEL używa się czterech typów obiektów. Są to: * kontrolery (dziedziczą po ap_ctrl) * widoki (dziedziczą po ap_show) * managery (dziedziczą po ap_mngr) * obiekty (dziedziczą po ap_obj) p. Dodatkowo zostały zaimplementowane klasy tzw. systemowe służące np. do obsługi przekazywanych przez serwer zmiennych lub mechanizmu cache (@ap_var@ oraz @ap_cache@). Ich omówieniem zajmiemy się później, teraz zajmijmy się typami obiektów opisanymi powyżej. h5. Kontrolery (obiekty klasy ap_ctrl) p. Obiekty tego typu odpowiadają za interakcję z użytkownikiem. Odbierają parametry i dokonują operacji na obiektach. Są również odpowiedzialne za umieszczanie widoków na stronie. Kontrolery implementujemy w katalogu @system/ctrl@. Tworząc nową aplikację powinniśmy na początku zdefiniować kontroler domyślny, czyli taki który będzie się uruchamiał przy wejściu na stronę główną naszego serwisu. Zwyczajowo nazywa się go @ctrl_main@ i jego definicję umieszcza się w pliku @system/ctrl/main.php@. h5. Widoki (obiekty klasy ap_show) p. Widoki generują nam fragmenty strony html. Każdy kontroler ma swój widok domyślny, nie ma jednak wymogu aby dla każdego z nich był inny. W szczególności wszystkie kontrolery mogą mieć ten sam widok domyślny i będzie to najczęściej spotykana sytuacja. Widoki można w sobie zagnieżdżać (dokładnie ten proces omówimy w dalszej części kursu). Do każdego widoku jest przypisany szablon smarty z którego generuje on kod HTML. Implementujemy je w katalogu @system/show@. h5. Managery (obiekty klasy ap_mngr) p. Managery są obiektami odwołującymi się już bezpośrednio do bazy danych, jednakże służą raczej do operacji grupowych na tabelach. Przy użyciu managerów możemy filtrować i wyszukiwać dane z bazy. Każdy manager ma przypisany do siebie obiekt klasy @ap_obj@ który zawiera informację o tabeli w bazie danych, dlatego też praktykuje się nazywanie managerów tak aby jednoznacznie kojarzyły się z obiektami i odpowiadającymi im tabelami. Trzymanie się tej zasady bardzo ułatwia zrozumienie kodu i może ograniczyć ewentualne błędy (od razu możemy skojarzyć jakiej tabeli i jakiego obiektu dotyczy manager na podstawie tylko jego nazwy). Managery implementuje się w katalogu @system/mngr@ h5. Obiekty (obiekty klasy ap_obj) p. Najprościej mówiąc pojedynczy obiekt tej klasy odpowiada pojedynczemu rekordowi w tabeli bazy danych. Obiekty tej klasy mają zaimplementowane automatyczne dodawanie oraz aktualizację informacji w bazie. Dobrą praktyką jest nazywanie obiektu podobnie jak nazywa się tabela w bazie do której się on odnosi, czyli tabeli o nazwie @moja_tabela@ powinien odpowiedać obiekt @obj_moja_tabela@. h5. Klasy systemowe p. Część operacji taka jak komunikacja z bazą danych, z cache czy też wysyłanie e-maili została zaimplementowana w tzw. klasach systemowych. Ich używanie nie jest wymagane, jednakże stanowią one spójną całość z resztą frameworku i ich użycie jest bardzo zalecane. Są to klasy @ap_bd@, @ap_cache@ czy @ap_mail@ → {toc} h3. Zasady nazewnictwa p. Aby w pełni wykorzystać mechanizmy zaimplementowane we frameworku musimy przestrzegać kilku zasad: h5. Baza danych p. Tabele w bazie powinny być nazywane w formacie nazwa_tabeli. Każda z tabel powinna posiadać klucz @PRIMARY@ o nazwie @nazwaTabeliId@. Jest to bardzo ważne gdyż zachowując taki format obiekty frameworku są w stanie automatycznie rozpoznać klucz główny tabeli i zautomatyzować operacje na bazie. Jeśli nie zachowamy takiego formatu nazewnictwa tabel, operacje odczytu i zapisu do tabeli będziemy musieli definiować sami. h5. Klasy p. Nazwa każdej klasy powinna być w formacie moja_nazwa_klasy, a jej definicja powinna znajdować się w katalogu @system/moja/nazwa/klasy.php@. W przypadku gdy nie zachowamy takiego formatu będziemy musieli jawnie używać instrukcji include bądź require. h3. Typy obiektów p. Do tworzenia aplikacji w oparciu o framework APEL używa się czterech typów obiektów. Są to: * kontrolery (dziedziczą po ap_ctrl) * widoki (dziedziczą po ap_show) * managery (dziedziczą po ap_mngr) * obiekty (dziedziczą po ap_obj) p. Dodatkowo zostały zaimplementowane klasy tzw. systemowe służące np. do obsługi przekazywanych przez serwer zmiennych lub mechanizmu cache (@ap_var@ oraz @ap_cache@). Ich omówieniem zajmiemy się później, teraz zajmijmy się typami obiektów opisanymi powyżej. h5. Kontrolery (obiekty klasy ap_ctrl) p. Obiekty tego typu odpowiadają za interakcję z użytkownikiem. Odbierają parametry i dokonują operacji na obiektach. Są również odpowiedzialne za umieszczanie widoków na stronie. Kontrolery implementujemy w katalogu @system/ctrl@. Tworząc nową aplikację powinniśmy na początku zdefiniować kontroler domyślny, czyli taki który będzie się uruchamiał przy wejściu na stronę główną naszego serwisu. Zwyczajowo nazywa się go @ctrl_main@ i jego definicję umieszcza się w pliku @system/ctrl/main.php@. h5. Widoki (obiekty klasy ap_show) p. Widoki generują nam fragmenty strony html. Każdy kontroler ma swój widok domyślny, nie ma jednak wymogu aby dla każdego z nich był inny. W szczególności wszystkie kontrolery mogą mieć ten sam widok domyślny i będzie to najczęściej spotykana sytuacja. Widoki można w sobie zagnieżdżać (dokładnie ten proces omówimy w dalszej części kursu). Do każdego widoku jest przypisany szablon smarty z którego generuje on kod HTML. Implementujemy je w katalogu @system/show@. h5. Managery (obiekty klasy ap_mngr) p. Managery są obiektami odwołującymi się już bezpośrednio do bazy danych, jednakże służą raczej do operacji grupowych na tabelach. Przy użyciu managerów możemy filtrować i wyszukiwać dane z bazy. Każdy manager ma przypisany do siebie obiekt klasy @ap_obj@ który zawiera informację o tabeli w bazie danych, dlatego też praktykuje się nazywanie managerów tak aby jednoznacznie kojarzyły się z obiektami i odpowiadającymi im tabelami. Trzymanie się tej zasady bardzo ułatwia zrozumienie kodu i może ograniczyć ewentualne błędy (od razu możemy skojarzyć jakiej tabeli i jakiego obiektu dotyczy manager na podstawie tylko jego nazwy). Managery implementuje się w katalogu @system/mngr@ h5. Obiekty (obiekty klasy ap_obj) p. Najprościej mówiąc pojedynczy obiekt tej klasy odpowiada pojedynczemu rekordowi w tabeli bazy danych. Obiekty tej klasy mają zaimplementowane automatyczne dodawanie oraz aktualizację informacji w bazie. Dobrą praktyką jest nazywanie obiektu podobnie jak nazywa się tabela w bazie do której się on odnosi, czyli tabeli o nazwie @moja_tabela@ powinien odpowiedać obiekt @obj_moja_tabela@. h5. Klasy systemowe p. Część operacji taka jak komunikacja z bazą danych, z cache czy też wysyłanie e-maili została zaimplementowana w tzw. klasach systemowych. Ich używanie nie jest wymagane, jednakże stanowią one spójną całość z resztą frameworku i ich użycie jest bardzo zalecane. Są to klasy @ap_bd@, @ap_cache@ czy @ap_mail@ "<<< Opis frameworku":http://www.xp-dev.com/wiki/67486/Opis%20frameworku - "Kontroler >>>":http://www.xp-dev.com/wiki/67486/Kontroler