[Warszawa-pm] WebNano

Wto, 21 Wrz 2010, 05:48:07 PDT

2010/9/21 piotr pogorzelski <pp w webtel.pl>:
>>
>> 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 ? ;)

Sporo rzeczy tutaj do przeanalizowania - ale na początek - to co
planuję z WebNano to właśnie eksperymentowanie w kierunku takiej
'klockowej budowy'.   Oczywiście wiele takich prób już było i wiele
jest bieżących eksperymentów próbujących tego dokonać - na pewno nie
jest to proste.  Mój plan opiera się przede wszystkim na tym co
pokazywałem na warsztatach w lipcu - czyli dziedziczenie aplikacji,
kontrolerów, templejtów itp.   Chodzi o to, żeby dało się napisać
aplikację, a później dziedziczyć z niej i podmieniać kolejne jej
fragmenty w miarę potrzeb.   A także, żeby dziedziczyć kontrolery -
jak na przykład operacje CRUD.  W Catalyscie da się dziedziczyć
kontroler (w przypadku całej aplikacji to już nie za bardzo) - ale
jego templejty już trzeba 'cut-and-paste'.  W WebNano wystarczy
napisac 'use base ...' i wszystko działa (no dobra - trzeba jeszcze
poustawiać ścieżki wyszukiwań, ale żadnego cut-and-paste).  To mam
nadzieje, pierwszy krok do tej 'klockowej budowy' - warunek wstępny -
a dalej zobaczymy.

Miałem kiedyś taki pomysł, żeby te klocki zacząć budować dla
Catalysta.  Powstał nawet pierwszy 'SimpleLogin' - ale Catalyst po
prostu wszystko komplikuje - i nie to, żeby to było niemożliwe - ale
okazuje się po prostu bardzo trudne.  Mam nadzieję, że prostszy
framework, wspierający explicite pewne wzorce projektowe, będzie miał
większe szanse tutaj.

Co do pisania własnych dispatcherów - w WebNano jest to tylko wtedy
konieczne gdy zwykłe mapowanie /Podkontroller/metoda/argument ->
App::Controller::Podkontroller->metoda_action( argument ) nie
wystarcza.   A dlaczego ten dispatcher jest dziedziczony w
kontrolerze?  Dzięki temu kontroller jest bardziej 'domknięty'
(encapsulated) i może być takim gotowym 'klockiem', jeśli dispatcher
jest na zewnątrz to jego połączenie z kontrollerem wymaga jakiejs
konfiguracji i nie da się go używać tak swobodnie.

Jeśli chodzi o narzucanie to moim zdaniem framework powinien raczej
narzucać API niż gotowe rozwiązanie - tak żeby można było te
rozwiązania poprawiać.  Generalnie to widzę to jako pewną ewolucję, co
do niektórych rzeczy jestem już pewien jak je należy realizować (po
długich doświadczeniach z Catalystem, CGI::Application itp), w
przypadku innych zamierzam jeszcze eksperymentować, w miarę jak będą
sie pokazywać dobre rozwiązania będą one coraz bardziej integrowane.

Pozdr.
Zbyszek