Amelia zawiera kilka głównych klas znacznie ułatwiających tworzenie aplikacji internetowej. Usprawnia ona znacznie konfigurację routingu (klasa Router), dostęp do bazy danych (biblioteka Medoo - PDO wrapper) oraz tworzenie widoku HTML (biblioteka Smarty). Wszystkie te podstawowe narzędzia dostępne są w bardzo przystępny sposób w klasie App (czyli aplikacji). Klasa ta zawiera zestaw statycznych metod dostępowych, za pomocą których możemy się do nich odwołać:

Klasa App - dostęp do głównych obiektów

App::getRouter() - zwraca obiekt routera (obiektu pozwalającego na dodawanie ścieżek - konfigurację routingu w aplikacji z możliwością określenia wymaganej roli)

App::getConf() - zwraca obiekt konfiguracji (ustawienia programisty aplikacji oraz wygenerowane na ich podstawie wartości)

App::getMessages() - zwraca obiekt Messages (pozwala na przekazywanie komunikatów do widoku)

App::getSmarty() - zwraca obiekt Smarty (silnik szablononowania - generowania widoków)

App::getDB() - zwraca obiekt Medoo ( ułatwia dostęp do bazy danych na podstawie danych ustalonych w konfiguracji - PDO wrapper)

Ten zestaw łatwo dostępnych obiektów pozwala stworzyć już kompletną aplikację internetową. Aby dowiedzieć się jak to zrobić zerknij na tutorial krok po kroku >>.

Klasy narzędziowe - pomocnicze

Amelia zawiera kilka dodatkowych klas pomocniczych, zawierających użyteczne narzędzia. Oto ich krótki opis:

Klasa Utils: zawiera metody upraszczające dodawanie komunikatów (Messages) i ścieżek do routera, również generowanie linków

Klasa RoleUtils: zawiera metody addRole (dodawanie roli), inRole (sprawdzenie czy użytkownik posiada daną rolę)

Klasa ParamUtils: zawiera metody pobierające parametry z żądania i sesji, takie jak getFromRequest, getFromGET, getFromPOST ...

Klasa SessionUtils: metody ułatwiające zapis i pobieranie danych z sesji (również zapis Messages i dowolnych obiektów)

Klasa Validator: bardzo pomocna przy pobieraniu i walidacji parametrów. Zobacz więcej w sekcji poświęconej walidatorowi >>

Pogrupowanie funkcji systemu w klasy optymalizuje ładowanie przez autoloader tylko potrzebnych, używanych w danym momencie funkcjonalności. Poza tym środowisko programistyczne precyzyjniej podpowiada składnię. Naturalnie wszystkie klasy pomocnicze umieszczono jak inne klasy frameworka w przestrzeni nazw '\core'.

Przyjazne linki

Amelia domyślnie pozwala wykorzystać przyjazne linki (ang. "pretty urls", "clean urls", "friendly urls"). Jest to ukrywanie "brzydkich" parametrów w URLu w ramach przyjętej konwencji.

Przykład: zamiast

http://www.domena.pl/index.php?action=main&name=ala&age=15

można stworzyć rozwiązanie przyjmujące tę samą liczbę parametrów przekazanych w ten sposób:

http://www.domena.pl/main/ala/15

W Amelii problem rozwiązuje się poprzez przekierowanie każdego żądania na kontroler główny, a inicjacja systemu sama pobiera te parametry z URLa do specjalnej tablicy. Parametry są dostępne za pomocą metod: ParamUtils::getFromCleanURL(...) lub przez obiekt walidatora (metoda validateFromCleanURL(...)). Przekierowanie każdego żądania (poza odwołaniami do istniejących plików, jak .css i inne dla przeglądarki) osiągnięto poprzez konfigurację serwera Apache dla aplikacji w pliku '.htaccess' (mod_rewirte)

Przesyłanie dodatkowych parametrów metodą GET jest dalej możliwe, np: http://www.domena.pl/main/ala/15?param1=xxx&param2=yyy
Dla domyślnie skonfigurowanych 'clean urls' we frameworku pierwsza pozycja jest akcją (pozycja o nr 0), a następne mają kolejne numery 1,2,3...

Możliwość ukrycia wszystkich skryptów i bibliotek aplikacji

Powyższe przykłady przyjaznych linków zakładają, iż www.domena.pl połączona jest na serwerze www bezpośrednio z podfolderem /public aplikacji. W innym wypadku, gdy aplikacja umieszczona jest w jakimś podfolderze względem domeny, przyjazny link będzie wyglądał inaczej.

Przykładowo, poprzedni przykład będzie mógł mieć postać:

http://www.domena.pl/aplikacja/public/main/ala/15

lub kolejny przykład dostosowany dla aplikacji umieszczonej domyślnie w ramach serwera Apache na komputerze lokalnym:

http://localhost/aplikacja/public/main/ala/15 

gdzie aplikacja to podfolder umieszczony 

Wynika to z faktu, iż podfolder /public jest głównym folderem, na który kierowany jest ruch przeglądarki (publicznie dostępne są również jego podfoldery). Gdy domena na niego nie wskazuje to należy się do niego odwołać jawnie. W razie odwołania http://localhost/aplikacja użytkownik zostanie automatycznie przekierowany do /public.

Więcej na temat konfiguracji aplikacji w tym kontekście znajdziesz na stronie opisującej config.php, czyli tutaj >>