Programowanie

Pierwszy z cyklu już bardziej konkretnych przemyÅ›leÅ„ i wizji dotyczÄ…cych poszczególnych komponentów “idealnego frameworka”. Tym razem chciaÅ‚bym omówić mojÄ… wizjÄ™ routingu gdyż jakby od niego wszystko siÄ™ zaczyna.

Routing w praktyce

Routing – to dziÄ™ki temu rozwiÄ…zaniu gdy użytkownik wywoÅ‚uje konkretne żądanie (adres i typ) router przekazuje polecenie do odpowiedniej części systemu. To on rozpoznaje i wykonuje pracÄ™ listonosza – dostaje konkretny adres i przekazuje tam dany list. We wczesnych rozwiÄ…zaniach routing istniaÅ‚ w bardzo uproszczonej formie. Requesty w postaci:

?action=kontakt

oznaczaÅ‚ tylko tyle, że jest gdzieÅ› wielki “switch” albo zestaw “else if” w których w zależnoÅ›ci od wartoÅ›ci parametru “action” wykonywany byÅ‚ konkretny blok kodu. OczywiÅ›cie później zostaÅ‚o to usprawnione o bardziej zamkniÄ™te funkcje, dodano inne parametry akcji. W zasadzie można by nazwać takie rozwiÄ…zanie bardzo prostym routingiem.

We współczesnych rozwiÄ…zaniach możemy spotkać routing w bardziej zaawansowanej formie, gdyż wiele frameworków stara siÄ™ implementować wzorzec MVC – chociaż osobiÅ›cie nie znam żadnego, który by w peÅ‚ni ten wzorzec implementowaÅ‚. MVC narzuca istnienie komponentów takich jak Model, Widok i Kontroler. Za kontroler przyjÄ™ta zostaÅ‚a klasa PHP która posiada różnorakie metody (akcje). W zwiÄ…zku z tym aby nieco uÅ‚atwić dostÄ™p do wykonywania poszczególnych akcji utworzono podstawowy wzór:

/controller/action

gdzie controller jest nazwą klasy kontrolera a action nazwą metody, która się w tej klasie ma uruchomić. Rozwiązanie proste i przyjemne. Podobne rozwiązanie funkcjonuje np w Zend Framework albo w Ruby on Rails. To rozwiązanie jest dobre do momentu gdy chcemy jednak zrobić coś bardziej skomplikowanego, np gdy:

• Specjalista SEO stwierdziÅ‚, że adres ma jednak wyglÄ…dać w postaci /nazwa_uzytkownika albo /kontroler,akcja.html
• Trzeba podzielić funkcjonalnoÅ›ci na bardziej logiczne części (np moduÅ‚y)
• Konkretne adresy maja funkcjonować w ramach konkretnej domeny (subdomeny) w wielomoduÅ‚owym lub wieloaplikacyjnym systemie

Jak sobie poradziÅ‚ z tym np Zend Framework? Ano jak to ZF, czyli “Zbuduj sobie sam”. Efekt jest taki, że robiÄ…c bardzo prosty adres, potrzebujÄ™ kilku linijek (przykÅ‚ad dla pliku INI)

routes.forum_topic_add.route = "nowy-temat"
routes.forum_topic_add.type = "Zend_Controller_Router_Route"
routes.forum_topic_add.defaults.controller = topic
routes.forum_topic_add.defaults.action = new

Whaaaat? ChciaÅ‚em tylko podać adres i wskazać go na konkretnÄ… akcjÄ™ do wykonania. O co tu chodzi? Poza tym to jest przecież jeszcze prosty adres. Nie ma tu żadnych wyrażeÅ„ regularnych. Gdybym chciaÅ‚ tak zrobić musiaÅ‚bym dostawić jeszcze kilka dodatkowych linijek na każdy parametr. Dodatkowo, żeby nie byÅ‚o za prosto musiaÅ‚bym zmieć router Zend_Controller_Router_Route na Zend_Controller_Router_Route_Regex – bo tamten już wyrażeÅ„ nie rozumie. Jeszcze, żeby byÅ‚o ciekawie poszczególne adresy można Å‚Ä…czyć w Å‚aÅ„cuchy a te Å‚aÅ„cuchy w kolejne Å‚aÅ„cuchy już z routerami i innym typie – np Static (tak jest jeszcze jeden typ). Tylko po co? Czy naprawdÄ™ programista musi mieć aż tak dokÅ‚adnÄ… kontrolÄ™ nad tym?

Wydaje mi się, że programista powinien po prostu pomyśleć sobie adres i wskazać którą metodę/funkcję ma on uruchomić. Wyobrażam to sobie tak:

nowy-temat = topic.new

I co tu potrzeba więcej? Adres taki i taki, ma kierować na taką i taką funkcję. Po co mi takie dokładne pisanie gdzie jaki kontroler a jaka akcja a jaki to typ routingu. Tym powinien już się przejmować framework a nie programista.

No dobra dobra, ale przecież to jest taki prosty przykład. A co z parametrami? W zendzie można użyć kontrolera Route albo Static. Np tak:

routes.archive.route = "archive/:year/*"
routes.archive.defaults.controller = archive
routes.archive.defaults.action = show
routes.archive.defaults.year = 2000
routes.archive.reqs.year = "\d+"

Powyższe rozwiÄ…zanie mówi tyle, że: jest wzór archive/:year. Ma ono odpalić kontroler archive i metodÄ™ show. A parametr :year ma być liczbÄ… a gdy a domyÅ›lnie ma przyjąć wartość 2000. W celach optymalizacji używa domyÅ›lnego routera, który uznaje za parametry wyrażenia po znaku “:” i separuje je po slashu. Tylko, że jest dodatkowa walidacja na to aby parametr year byÅ‚ liczbÄ…. Moim zdaniem zupeÅ‚nie niepotrzebna komplikacja. PrzykÅ‚ad poniżej jest nieco inne podejÅ›cie:

routes.archive.type = "Zend_Controller_Router_Route_Regex"
routes.archive.route = "archive/(\d+)"
routes.archive.defaults.controller = "archive"
routes.archive.defaults.action = "show"
routes.archive.map.1 = "year"

Wzór routingu już jest zapisany bezpośrednio w adresie ale z kolei teraz trzeba w osobnym miejscu ponazywać poszczególne parametry. Znowu jakimś nowym cudacznym sposobem, który wymaga uruchomienia jakiegoś specjalnie napisanego parsera, gdzie jedne robi tak, a inny tak. Moim zdaniem idealny framework powinien oferować kompleksowe. jednolite rozwiązanie problemu. Programiści Zend Framework chyba sami nie znają za bardzo możliwości języka w którym piszą, bo jak inaczej wytłumaczyć fakt nie skorzystania z podstawowej umiejętności wyrażeń regularnych jaką jest named subpattern. Widziałem multum przykładów z różnymi konfiguracjami routingu ale nigdy nie widziałem tego prostego zastosowania. Ze strony PHP

preg_match('/(?\w+): (?\d+)/', $str, $matches);

dzięki temu funkcja do wyrażeń regularnych automatycznie podstawia nam klucze sparsowanych parametrów jednocześnie dbając o poprawną walidację związaną z podanym typem wyrażenia. Sam nie jestem orłem jeśli chodzi o wyrażenia regularne ale to jest na tyle proste, że każdy to zrozumie. Dzięki temu można budować dowolnie skomplikowane adresy do routera. i bardzo proste i bardzo skomplikowane zachowując całkowitą spójność w sposobie ich tworzenia.

forum/(?