MalDevBlog

Wiem, że powinienem w tym czasie zamiast bawić się w PHP rozwijać te kilka ważnych projektów w C++, ale doszedłem do wniosku, ze poświęcę jeszcze trochę czasu na uporządkowanie kilku spraw i projektów. A potem zabrać się za komunikatora ;)

Notatka nie będzie dotyczyć zabaw z typowym routerem, mowa tu o komponencie/module frameworka odpowiedzialnym za obsługę żądań (requestów) i spraw związanych z generowaniem linków.
Może nie jest to typowe, modelowe zadanie routera, tak czy owak w moim małym, skromnym frameworku spełnia takie funkcje ;)

Właśnie kończę implementacje odpowiedzialna za parsowanie requesta i wyciągnie odpowiednich danych o kontrolerze akcji i dodatkowych parametrach.

Wcale ten router nie jest taki inteligentny jak może sugerować tytuł, jest on trochę ironiczny :P

Jednym z głównych założeń routera było zbliżone działanie do tego z CodeIgnitera, a mianowicie możliwość „inteligentnego odpalania” kontrolerów z subf-olderów z nieco większa elastyczność niż rozwiązanie zastosowane w CI. Tam (chyba) tylko kontroler mógł być zagnieżdżony o 1 poziom w sub-folderze względem głównego folderu zawierającego kontrolery.
Ja u siebie nie chciałem się ograniczać jednym poziomem - chcę mieć nieograniczoną możliwość zagnieżdżania folderów w dół.

Dla pliku ustaliłem większy priorytet niż dla katalogu, tak, więc może kilka przykładów, które rozjaśnia zasady działania mojej implementacji.

Przy okazji, z ostatniego członu requesta będzie wycinane .html, jeśli takowe się tam znajdzie.

Mamy requesta:

http://domena.com/foo/bar/param.html

Jaka zostanie odpalona akcja, z którego kontrolera i z jakimi parametrami?
Zależy to od struktury i rozmieszczenia pliku kontrolera, rozważmy kilka przypadków:

1. W głównym katalogu kontrolerów istniej plik foo.php, tak wiec, wywołana zostanie akcja bar z parametrami param kontrolera foo.
2. W katalogu foo/ istnieje plik bar.php z definicja kontrolera.
   W tym wypadku użyty zostanie kontroler bar znajdujący się w sub-folderze foo, a akcją będzie metoda param.
3. Połączenie 1 i 2, czyli istnieją pliki i foldery według 1 i 2 przypadku.
   Oczywiście wynik będzie taki jak w przypadku 1. Jak wspomniałem plik ma większy priorytet niż katalog ;)
4. Istnieją katalogi według ścieżki foo/bar/ ale bez żadnych odpowiednich plików.
   Router w tym przypadku ustawia jako kontroler – domyślny kontroler (index) znajdujący się w folderze foo/bar/, a jako akcje – param.

W przypadku requesta:

http://domena.com/foo.html

Router jeśli znajdzie plik kontrolera foo, to wywoła metodę domyślną (index) tego kontrolera. Jeśli nie znajdzie pliku, a będzie istniał katalog foo/ to wywoła domyślną akcje domyślnego kontrolera z tego katalogu.

Ja bym chciał na przykład w takim przypadku, aby została wywołana domyślna akcja z parametrem foo domyślnego kontrolera.
Wpadłem wiec na pomysł, aby dodać do kontrolera dodatkową właściwość.
I zależnie od jej wartości, jeśli w danym kontrolerze nie zostanie znaleziona szukana akcja, to zostanie przyjęta domyślna akcja z parametrem. Oczywiście parametr ten byłby ustawiany w czasie projektowania (a może i nie tylko) danego kontrolera i miałby widoczność lokalna ;)

Pozostaje jeszcze kwestia filtrowania requesta pod katem „złych/niebezpiecznych” znaków ;)

Pewnie niektórym nie spodoba się takie podejście i rozwiązanie, ale w końcu to będzie mój framework, prosty framework (bez dzielenia 4 funkcji na 40 klas i rozrzucania po 10 folderach!), z którego głównie pewnie tylko ja będę korzystał, więc powinien spełniać jak najbardziej moje potrzeby i ułatwiać mi prace ;)