Fowardowanie akcji

Od kilku dni prace nad frameworkiem (lub tym czym to na razie jest) nie posuwaj się naprzód, a to z kilku powodów. Jednym z nich są napotkane trudności, a drugim inne zajęcia, bardziej lub mniej ważniejsze (m.in. grzebanie w asemblerze i „czystym” C).
Mam nadzieje, że wkrótce wrócę do tego kodu.

Ta wspomniana trudność, jaka mi stanęła na drodze to fowardowanie. A dokładniej pewna sytuacja przy fwardowaniu kontrolera/akcji. Mianowicie, jeśli w danej akcji będziemy chcieli uruchomić inną akcje z innego kontrolera, a akurat ten kontroler będzie miał taka sama nazwę jak bieżący, to niestety się rozczarujemy – nie zostanie w ogóle załadowany, ponieważ klasa o nazwie kontrolera już została zdefiniowana, a nie ma możliwości redefinicji. To, że będzie znajdował się w innym sub-folderze niczego nie zmieni.
Ot cały problem.

Dziś akurat wpadło mi do głowy pewne rozwiązanie.

Jeśli wystąpi sytuacja opisana wyżej, to fowardowanie uruchomi redirecta na żądana akcje/kontrolera.
Wydaje mi się, ze to będzie najlepsze rozwiązanie ;)

Myślę tez 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 na przykład kontroler cNewsy i model mNewsy, będzie wiadomo na pierwszy rzut oka, że są ze sobą ‘związane’ i łatwiej będzie można się zorientować w strukturze.

Mój prosty framework :P
Chyba jeszcze nie zasługuje to na taka nazwę, bo wiele jeszcze brakuje. Póki co jest tylko implementacja prostego loadera, routera, front controllera, abstrakcja kontrolerów. Brakuje modeli, i widoków, a bez nich nic nie ruszy ;)

8 przemyśleń nt. „Fowardowanie akcji”

  1. 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.

  2. 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.

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

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

    Ciekawy pomysl i chyba go wykorzystam ;)

    Jak pisalem, problem wystepuje tylko w skrajnych przypadkach, wiec parsowanie bedzie tylko jesli ladowana classa juz zostala zdefioniowana.
    Po co tracic na wydajnosci w innych okolicznosciach, gdzie wystarczy include ;)

  5. 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.

  6. IMHO zalezy od implementacji.
    U mnie kontroler jest zbiorem kilku akcji, cos podobnego jak w CI. Kontrolery moga byc zagniezdzane w sub-folderach, aby stosowac prosty routing do bardziej skomplikowanych requiestow ;)

    Dwa kontrolery wystapia conajmniej, np. defaultowy w glownym katalogu i defaultowy w jakims sub-folderze. O opisuywany problem wystapi, gdy z jednego bede chcial fowardnac sie na drugi :P

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *