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)

php blog avatar
php blog
20070717-074029-php-blog

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.

Elf avatar
Elf
20070717-112330-elf

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.

Michał Słaby avatar
Michał Słaby
20070717-183905-michal-slaby

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 ;-)

MalCom avatar
MalCom
20070717-185855-malcom

wczytać zawartość pliku php, wyparsować to, co znajduje się pomiędzy class a extends, zamienić na unikalny identifikator … i evelować

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 ;)

Yacho avatar
Yacho
20070718-154016-yacho

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.

MalCom avatar
MalCom
20070719-154200-malcom

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.

Turgon avatar
Turgon
20070722-213249-turgon

Tak zupełnie na marginesie forwardowanie wg mnie powinno być ;)

Dodaj komentarz

/dozwolony markdown/

/nie zostanie opublikowany/