Forwardowanie akcji w PHP
• tech • 272 słowa • 2 minuty czytania
Od kilku dni prace nad frameworkiem (lub tym czym to na razie jest) w PHP nie posuwają się naprzód, a to z kilku powodów. Jednym z nich są napotkane trudności, a drugim inne, bardziej lub mniej ważniejsze zajęcia (m.in. grzebanie w asemblerze i “czystym” C). Mam nadzieję, że wkrótce wrócę do tego kodu.
Ta wspomniana trudność, jaka mi stanęła na drodze to forwardowanie. A dokładniej to pewna sytuacja przy forwardowaniu kontrolera/akcji. Mianowicie, jeśli w danej akcji będę chciał uruchomić inną akcję z innego kontrolera, a akurat ten kontroler będzie miał taką samą nazwę jak bieżący, to niestety się rozczaruję - nie zostanie w ogóle załadowany, ponieważ klasa o takiej nazwie kontrolera już została zdefiniowana, a nie ma możliwości redefinicji. To, że będzie znajdował się w innym podkatalogu niczego tu nie zmieni. Ot cały problem.
Dziś akurat wpadło mi do głowy pewne proste rozwiązanie. Jeśli wystąpi sytuacja opisana wyżej, to forwardowanie uruchomi redirecta na żądaną akcję/kontrolera. Wydaje mi się, że to obecnie będzie najlepsze rozwiązanie ;)
Myślę też nad wprowadzeniem przedrostka do nazw klas (i może plików) kontrolerów i modeli - odpowiednio c i m. Uchroni to przed podobnymi problemami do tych wyżej opisanych oraz umożliwi łatwe i “powiązane” nazewnictwo pomiędzy poszczególnymi elementami, na przykład kontroler cNews i model mNews. Będzie wiadomo na pierwszy rzut oka, że są ze sobą “związane” i łatwiej będzie można się zorientować w strukturze projektu.
Mój prosty framework w PHP powoli rośnie…
Chyba jeszcze nie zasługuje to na taką nazwę, bo wiele jeszcze brakuje. Póki co jest tylko implementacja prostego loadera, routera, front controllera i abstrakcja kontrolerów. Brakuje modeli i widoków, a bez nich nic nie ruszy ;)
Komentarze (7)
Osobiście u mnie jest jeden kontroler obsługujący wszystkie akcje, nazwy akcji są unikalne i pogrupowane w foldery, które to wyznaczają podział na moduły. Oczywiście każdy to widzi na swój sposób, ale ja dążyłem u siebie do prostoty, a nie wymyślnych reguł w nazewnictwie czy strukturze.
Ustal sobie konwencję nazewniczą i się jej trzymaj. Wiem, niełatwa sprawa z wymyśleniem takowej, ale to nie problem, gdyż większość FW taką ma - można skopiować :) Zend ma konwencję wywodzącą się z PEAR. Wydaje mi się ona dość powszechna i całkiem prosta w zastosowaniu.
Możesz ładować klasy kontrolerów pośrednio, tj. wczytać zawartość pliku php, wyparsować to, co znajduje się pomiędzy class a extends, zamienić na unikalny identifikator uzyskany powiedzmy przez microtime i evelować. Działa bez pudła. Udało mi się nawet zasymolować eksportowanie źródła klasy ze zdalnego serwera po to, by zevalować je wewnątrz bieżącego skryptu php i wykonać - taki ServiceLocator dla ubogich ;-)
Ciekawy pomysł i chyba go wykorzystam ;)
Jak pisałem, problem występuje tylko w skrajnych przypadkach, więc parsowanie będzie tylko jeśli ładowana klasa już została zdefiniowana. Po co tracić na wydajności w innych okolicznościach, gdzie wystarczy
include;)Istnieje podstawowe pytanie : po co w ogole w aplikacji dwa tak samo nazwane kontrolery ? uwierz że jeśli aplikacja ma dwa tak samo nazwane kontrolery jest napisana błędnie. Kontroler ma to do siebie ze operuje na danej encji. konroler A powinien operowac bezposrednio tylko na encji A reszte o ile sa mu potrzebne zalatwiac relacjami. I koniec tematu - konwencje nazw sa po to zeby poprzez ograniczenia “dowolnosci” prowokować dobry design - i to on powinien byc priorytetem a nie pełna elastycnosc przestrzeni nazw.
IMHO zależy od implementacji.
U mnie kontroler jest zbiorem kilku akcji, coś podobnego jak w CI. Kontrolery mogą być zagnieżdżane w sub-folderach, aby stosować prosty routing do bardziej skomplikowanych requestów ;)
Dwa kontrolery wystąpią co najmniej, np. defaultowy w głównym katalogu i defaultowy w jakimś sub-folderze, wtedy opisywany problem wystąpi, gdy z jednego będę chciał “forwardnąć” się na drugi.
Tak zupełnie na marginesie forwardowanie wg mnie powinno być ;)