[Warszawa-pm] WebNano

[piotr pogorzelski]

>
> Dzięki - nareszcie widzę, że ktos mi toprzeczytał :)   A odpowiadając
> na pytanie - problem jest z metodami takimi jak wlasnie na przykład
> 'local_dispatch' - co zrobić, żeby użytkownik nie mógł namieszać?
> Zastanawiam się teraz czy możliwe byłoby po prostu zamiana wszystkich
> takich funkcji na "prywatne" to znaczy z prefixem '_' i odróżnianie
> tego w ten sposób, ale to chyba jednak zbyt kłuciłoby się z tym co
> normalnie się uważa za prywatne - bo 'local_dispatch' nie jest
> prywatne w takim ogólnie przyjętym sensie.
>


nie wiem co robi local_dispatch ;)

ja bym nie uzywal dziedziczenia w dispaczerach, tylko wywolywal nimi
funkcje z innych modulow. proste mapowanie url na funkcje.

zamienal /strona na App::ROOT::strona i tyle.

moze jesli metoda zaczyna sie od podkreslenia to bym nie wywolywal - 
jedyne ustepstwo. cos ala pliki ukryte.

jesli modul App::ROOT::katalog mialby funkcje dhandler
wywolywalbym ja gdy nie znaleziono metody pasujace do url
(np /katalog/strona1 wywoluje App::ROOT:katalog::dhandler gdy nie ma 
metody App::ROOT::katalog::strona1)

jesli bylaby metoda header i footer wywolywalbym je wokol
wywolywanej metody. (albo autohandler wywolywane 'around'
strona1)

wtedy nie musialbym pisac wlasnych dispatcherow tylko metody
w modulach.

to o czym pisze to takie przeniesienie z HTML::Mason ale tamto
mi bardzo odpowiadalo. bylo intuicyjne i w ogole nie trzeba
bylo zagladac do masona a mialo sie pelna wladze nad
kolejnoscia wywolan metod/stron/modulow

to co lubie w masonie jest to, ze to jest perl i nie musze
sie uczyc jezyka np TT aby cos zrobic.

oczywiscie fajnie jest miec TT gdy masz kogos kto robi layout
ale aby z tego korzystac trzeba sie nauczyc nowego jezyka

dlatego to jak dzialal mason. proste regulu - wstawiam plik
jest strona. autohandler dhander i nie musze nic wiedziec
o bebechach.

tutaj trzeba pisac wlasne dispatchery. w catalyscie
stwierdzilem, ze najwygodniej mi wszystko pisac jako jedna
funkcje w kontrolerze root. czyli pisac jeden dispatcher,
bo ma jendo miejsce gdzie weryfikuje,mapuje, modyfikuje
parametry jakie przychodza z przegladarki itp.


do tego parsowanie argumentow wywolania w dispatcherze.


w konfigu aplikacji podawalbym klase, ktora odpowiada za dispaching.
wtedy ktos moglby pisac wlasne, gdyby potrzebowal.

wiec w sumie moge sobie takiego napisac i podpiac pod webnano.

najwazniejszym sie staje dokument WebNano Best Practices
czyli jak zrobic sesje, autoryzacje, autentykacje, odczytywanie
zalacznikow itp.


jak budujesz sajty, fajnie by bylo moc latwo integrowac gotowe elementy.
tak aby na stronie wstawic kwadracik diva odpowiedzialnego np za sonde.

wstawiam na stronie taki element i on juz generuje odpowiednie urle,
ktore sa potem mapowane do odpowiednich metdod z zainstalowanego 
plugina. wtedy mozna by rzeczywiscie budowac sajty jak z klockow lego.
wstawiam klocek i nie musze nic wiecej robic. jesli jest napisany
pod frejmlork potrafi sobie sam wszystko zorganizowac podpiac sie
do dispaczera, sesji itp.

dlatego wazne jest, aby frejmlork z wielu roznych sposobow na jakie
mozna zrealizowac pewne dzialania wybieral arbitralnie jeden
i narzucal, ze te i te wylistowane z nazwy problemy nalezy
rozwiazywac w ten jeden konkretny sposob - i dawal narzedzie
realizujace rozwiazenie tego problemu.

zaczac od podstawowych problemow - sejsa, autoryzacja
i dodawac nowe mechanizmy w miare potrzeb i rozwoju.
byle byl ten jeden wlasciwy.

wtedy mozna mowic o kompatybilnosci powstajacych modulow.
takiej, ze moge blyskwaicznie podpiac cos, co ktos zrobil dla siebie

a taka klockowa budowa wymaga aby obiekty potrafily same sie
renderowac, uwzgledniajac aktualny kontekst adresu strony, sesji,
uzytkownika czyli musialyby miec dostep do glownego obiektu
aplikacji.

tylko, czy to juz nie zostalo kiedys zrobione ? ;)

--
pp