[Warszawa-pm] WebNano

[piotr pogorzelski]

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

hmm, dla mnie "klockowa budowa" to wlasnie przeciwienstwo dziedziczenia.

to taka architektura gdzie klocki nic o sobie nie wiedza poza 
standardowym inteferjsem przez ktory sie komunikuja - jak to maja 
klocki.  i frejmlork ma zapewnic aby srednica dziurek byla odpowiednia i 
byly w odpowiedznich miejscach aby pasowaly do siebie.

dziedziczenie to obklejanie klocka i tworzenie z niego nowego,
innego klocka. nie o to mi idzie.

ale dajmy spokoj klockom, bo zaczniemy gadac o klockach zamiast
programowaniu.

mi sie marzy cos, co wkladam na strone i dziala z moja strona.
generowane sa wszystkie urle ktore automatycznie prowadza
do handlerow zapewnianych przez klocek.

jak chce go zmodyfikowac aby dzialal ciut inaczej, dopiero wtedy
wchodzi na scene dziedziczenie.

wyobrazam sobie, ze wgrywam plugin, dodaje do konfiga.
to mi rejestruje wszystkie handlery tam gdzie trzeba.
w templejcie uruchamiam renderer, ktory generuje linki
zwiazane z klockiem wzglednie urla strony, na ktorej
zostal umieszczony i one dialaja bo dispaczer
ma juz zarejestrowane do jakich metod klocka je przekierowac.

i ja w swojej aplikaci, w idealnej sytuacji nic nie musze
pisac. tylko konfig i rendering klocka w templejcie.

chyba ciagniemy w przeciwnych kierunkach ;)

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

prosty frejmlork, z okreslonymi zasadami i narzedziami
realizujacymi te zasady na pewno pomoze. inaczej jest mnostwo
kawalkow, czesc pasuje do jednych, nie pasuje do innych

to jak z moose. standard de facto. mozna robic inaczej, po swojemu.
tylko, ze wtedy zostaje sie poza glownym nurtem - abstrahujac
gdzie jest glowny nurt.

>
> 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.
>
coz. co dla ciebie zaleta, ja postrzegam jako wade. widac inaczej
myslimy :)
dla mnie frejmlork powinien byc czyms czego nie modyfikuje.
nie dziedzicze po nim. on mi tylko przynosi dane, zapewnia transport
i daje mechanizm sterowania przeplywem kodu ( w sensie co kiedy jest
uruchamiane), wspomaga w renderingu i zapewnia standardowe
mechanizmy niezbedne w aplikacjach (sesje itd.)

moim zdaniem dziedziczenie jest dobre w bibliotekach, gdy panuje nad
tym jeden programista. moze zespol.  potem juz nie jest tak slodko.

stad moje ciagoty do klockow, ktore nic o sobie nie wiedza,
konsumuja pewne parametry, zapewniaja rendering i obluge wygenrowanych
przez siebie urli.


> 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.
ewolucja tak. ale jak sie nie da na poczatku czegos takiego jak
libc, to kazdy napisze swoje. do obslugi podstawowych rzeczy.

chetnie uslysze, czego jestes pewien, do jakich wnioskow doszedles.
to bardzo mnie ciekawi.

moim zdaniem tyle tych frejmlorkow jest, bo ich autorzy
dochodzili do roznych wnioskow i realizowali je tworzac te
frejmlorki. i potem wazne znac takie glowne zalozenia, bo to
od razy przyciagnie cie lub ostrzeze, ze mozesz miec
pod gorke ze wzgledu na swoje inne wyczucie tematu.

czyli nie pozostaje mi nic innego jak napisac wlasny WebKloc ;)