Witam,

Nie wiem czy pamiętacie, ale kiedyś była taka dobrze zapowiadająca się gra, nazywała się Duke Nuke Forever. Jestem trochę starawy, także dobrze pamiętam te czasy. Obiecywali złote góry, czekoladowa ścieżki, rzeki miodem (i piwem) płynące, jednak gdy gra ostatecznie wyszła, wtedy... nie wiem, czy ktokolwiek ją kupił - mniejsza z tym.

Nie wiem co mnie natchnęło, ale postanowiłem zajrzeć na stronę yii - i ze zdziwieniem stwierdziłem, że w tym miesiącu wyszła wersja 2.0! Tak, pamiętam gdy oczekiwałem na nią. Pierwsza wersja Yii była zachwalana pod niebiosa - tak samo jak i jej druga część, która była rozwijana od 2011 roku.

W końcu nadszedł czas, na horyzoncie pojawiło się Yii 2.0 - co prawda emocje już zostały mocno wypalone (te 2 lata temu jakoś bardziej mi zależało na tym, aby użyć tego frameworka), jednak zajrzałem do dokumentacji w oczekiwaniu na coś ciekawego, jednak...

Jednak to co ujrzałem, to standard.

Wszystko to, co w każdym FW, którego używałem. Nie wiem, czy ja zamieniłem się w jakiegoś zgreda, czy po prostu naprawdę wszystkie Frameworki PHP są takie same - proszę o diagnozę. Przejrzałem dokumentację i widzę, że tam jest wszystko to, co w pozostałych FW. Zero nowości, kurde...

Czy coś pominąłem? Proszę o odpowiedź jakiegoś interesanta Yii (a może nawet i fanboya).

Dokładnie, wszystkie robią to samo. Różnią się tylko możliwościami i konfiguracją. Szkoda, że tak jest, zwłaszcza, że yii wywodzi się z Prado, który jednak przedstawiał całkiem inne podejście.

Bardzo lubię Yii 1.x i jeżeli mam do zrobienia jakiś projekt to pracuje na nim. Lekki, prosty, ma wszystko co trzeba. Nie wiem jaki minus może być. Wsparcie duże, świetna dokumentacja, masa rozszerzeń.
Gii to genialne narzędzie - generujesz modele, kontrolery, formularze, nawet gotowy CRUD łącznie z widokami

Ja ostatnio patrząc na to co dzieje się w świecie JS zaczynam się zastanawiać czy PHP nie pójdzie tą drogą tylko jak zawsze trochę wolniej. Wszystkie FW JS zaczęły się do siebie bardzo upodabniać (w PHP odkąd zaczęto stosować DI już praktycznie wszystkie działają tak samo), niedawno ogłoszono koniec rozwoju YUI, Dojo i jQuery tkwią w miejscu przy coraz lepszych możliwościach przeglądarek i już nawet nie są tak bardzo potrzebne. Widzę pewien odwrót od monolitycznych rozwiązań na rzecz niezależnych małych bibliotek realizujących określone funkcje. Gołe PHP też zyskuje coraz większe możliwości, popularniejsza staje się idea JIT, dzięki przestrzeniom nazw coraz częściej tworzy się małe przenośne moduły. Może niedługo w PHP też nie będą potrzebne duże biblioteki tylko każdy poskłada projekt z "bundli" które lubi.

Ogólnie to jakiś czas temu zdałem sobie sprawę z tego, że cała sieć i frameworki to najzwyklejsze i najprostsze wejście/wyjście do naszej aplikacji oparte na łańcuchach znaków. Można nawet powiedzieć, że komiczne jest to, jak bardzo architektura frameworków i setki frameworkowych "bajerów" zdominowały aplikacje webdeveloperów (trzymając ich za jaja).

Jak to powiedział jeden programista z 40-letnim stażem (Martin C. Robbins) - architektura polega na wiedzy jak rysować strzałki - zgadzam się z nim!

Niestety zbyt wiele strzałem skierowanych jest z aplikacji w stronę pluginów (frameworków).

Stało się to na co wszyscy czekali od samego początku. Ujednolicenie sposobu działania, spójnych standardów, aby zmieniając narzędzie nie tracić czasu na myślenie jak to działa.

Teraz otwiera się droga dla kogoś, kto wymyśli coś nowego

Nie będzie nowego. Cofniemy się w czasie i modne będzie klepanie strukturalne, coś na wzór trendu projektowania płaskiego UI ala lata 90. Choć pod nową nazwą.

Nie tracić czasu na myślenie, powiadasz? Racja, ja odnoszę wrażenie, że misją dzisiejszych frameworków jest kompletne oduczenie programistów myślenia. Framework ma ogłupić programistę, przedstawić mu dziesiątki cukiereczków (moduły do wszystkiego, od tworzenia formularzy, po walidację danych, czy dziesiątki pomocniczych funkcji) - a wszystko po to, aby ten biedny, wygodnicki, ogłupiały programista używał ich wszedzie, w co drugiej linijce swojej aplikacji i aby nie mógł się już za chiny oderwać od frameworka. ; )

To takie piękne, przymusowe małżeństwo - żonka (framework) przedstawia swoje "pyszności", programista je "kosztuje", cieszy się nimi, a później nie wiadomo kiedy okazuje się, że jest już dawno po ślubie i nie wie kiedy się to stało - a o rozwodzie nie ma szans nawet myśleć.

Małżeństwo dobra rzeczy, ale... frameworki tak szybko się "rozwijają" - piszę w cudzysłowie, bo tak naprawdę niewiele wnoszą do życia, a cyferki w wersjach ciągle rosną, a z nimi adnotacje "brak kompatybilności". I taki biedny, ogłupiały programista nacieszy się tym frameworkiem, wejdzie w to małżeństwo, a po roku dowiaduje się, że na horyzoncie jest nowa wersja. I co? I... nie ma mowy o przeniesieniu aplikacji na nowego frameworka, bo to co napisał jest spięte setkami małych nici ze starym frameworkiem - bo tu użył jakiejś funkcji pomocniczej (bo mu się nie chciało pisać własnego przenośnego rozwiązania), a tam użył jakiegoś innego "frameworkowego cukiereczka", i tak sobie siedzi i nawet nie zdaje sobie sprawy z tego, że jedyne czego tak naprawdę potrzebował to klasy do obsługi routingu, ewentualnie kontrolera i klasy do obsługi zapytań do bazy danych.

Ale... wybrał framework, wyszła nowa wersja... O! Wypadałoby się z nią zapoznać i coś napisać, a może i przenieść starą aplikację? Przy okazji - za dwa lata będzie kolejna wersja, a za kolejne dwa jeszcze kolejna. Też wypadałoby się z nimi zapoznać. I to tak porządnie, poznać jej wszystkie moduły i cukiereczki - i najlepiej w przyszłości napisać aplikacje tak, aby przyszłe wersje frameworków trzymały pisaną aplikację za jajca tak mocno, aby nie można było oderwać się od tych wersji. ; )

Tak, uwielbiamy te wszystkie małe, malutkie, niewinne funkcje, klasy i moduły frameworków. Jest ich tak wiele, można za ich pomocą robić tak wiele - i wiecie co? Najlepiej jest używać ich w kodzie aplikacji. W naszym kodzie. Nieeee, nie używajmy adapterów, nie róbmy żadnych granic, używajmy w naszym kodzie - bezpośrednio - wszystkich funkcji, metod, modułów frameworka. Niech trzyma nas za jaja! Mocno! Tak, tego chcemy!

Niech żyją standardy, niech żyją frameworki MVC! ; D

Mylisz się, nie wszyscy.


To Twoim zdaniem czym jest framework (jeśli nie szkieletem aplikacji)? Jeżeli nie chcesz szkieletu to pisz wszystko sam albo wykorzystuj niezwiązane ze sobą biblioteki. Pełna dowolność.


Jeżeli uważasz, że zmiana numeru w symfony 1 na 2 wniosła niewiele to nie wiem jak mam to interpretować. Co do kompatybilności to zobacz jak w Symfony 2 ma się podejście do kompatybilności.


I nic. Aplikacja śmiało może nadal stać na starszej wersji.


To już wybór programisty aplikacji jak korzysta z narzędzi.

Tak jak pisałem wcześniej - framework to narzędzie, biblioteka, plugin - frameworki PHP to obsługa wejścia/wyjścia z dziesiątkami dodatkowych bajerów.

Mówisz, że framework to szkielet - ale powiedz mi co w nim jest niby szkieletem? Czy to, że jeśli do wejścia wyślę string "http://ksiazki.pl/przegladarka/Przygody-jasia" i
framework "uruchomi" kontroler "przegladarki" z argumentem "Przygody jasia" oznacza, że to ma cokolwiek wspólnego z moją aplikacją? I że jest niby szkieletem?

Ja tu widzę tylko zwykły mechanizm wejścia/wyjścia. Framework działa jak "interfejs GUI", który przekazuje aplikacji informację nt. poczynań użytkowników.
Jedyne co farmework powinien zrobić, to przekazać apce stringa "Przygody Jasia", a apka powinna przyjąć to jako argument - i nie powinna nawet wiedzieć czy
to ją wysłał Zend, Symfony, Laravel, czy Progamista Zenek odpalając kod aplikacji z linii poleceń.

Aplikacja zawiera swoją osobną logikę, architekturę - a także tworzy swój szkielet.

Prosty mechanizm komunikacji (routing + controlery), a także biblioteka do obsługi bazy danych wrzucana jako model to żaden szkielet. To proste mechanizmy, które
niestety zbyt często bezmyślnie wrzucane są we właściwym kodzie aplikacji - a jak wiemy "Coupling" to najgorsze zło w programowaniu.

To jestem ciekaw czym dla Ciebie jest ta apka bo kompletnie nie wiem o czym piszesz. Nie wiem do czego zmierzasz. Może przedstaw jakiś kawałek (pseudo)kodu, który zobrazuje to co chcesz przekazać.


Czemu żaden szkielet? To właśnie jest szkielet.

Mam tutaj na myśli logikę biznesową.



Okay, w wolnej chwili postaram się przestawić jaśniej to o czym piszę.



Czy na pewno jesteś pewien, że kod odpowiedzialny za komunikację użytkownika z Twoją logiką biznesową
jest szkieletem? To tak jakbyś powiedział, że "Event Listener" w JavieScript to szkielet.

Frameworki to zwykłe kanały informacji z dodatkowymi bajerami, które można wykorzystać, ale czy
naprawdę trzeba je mieszać z logiką biznesową?

Gdybyś od razu napisał, że chodzi Ci o logikę biznesową czyli o model to byłoby łatwiej się dogadać. Ja osobiście staram się tworzyć aplikacje w ten sposób, że tworzę model. Potem korzystam z jakiegoś szkieletu, który pomoże mi skomunikować mój model z użytkownikiem.


Źle kombinujesz, zaraz napiszesz, że array() to jest frameworkiem bo służy do komunikowania z użytkownikiem.

Z premedytacją unikałem użycia słowa "model", ponieważ przywołuje on skojarzenia z modelami z MVC, które są mocno uproszczone i wiele osób może je skojarzyć wyłącznie ze zwykłą biblioteką ORM. Także logika biznesowa i kod operujący tą logiką to właśnie to co określam właściwą aplikacją - tj. wszystko to, co piszemy sami (można powiedzeć, że to wszystko co zaczyna się w kodzie kontrolerów).

Całym meritum sprawy o której piszę to przenośność i niezależność naszych aplikacji. Wcześniej pisałem je w taki sposób jak wszyscy, tj. uważałem framework jako
podstawę mojej aplikacji, jako serce mojego "dzieła", które było całkowicie zależne od frameworka - i przez myśl mi nawet nie przychodziły takie rzeczy jak przenośność,
niezależność. Nawet przez milisekundę nie zastanawiałem się nad pytaniem: "A co jeśli chciałbym zmienić framework, albo system ORM? Ile czasu zajęłoby mi przepisywanie
mojego kodu na nowy framework? Iloma "cienkimi niciami" moja aplikacja powiązana jest z frameworkiem?".

Ale pewnego dnia jedna osoba sprawiła, że zacząłem zastanawiać się nad tym, ogólnie nad zasadami SOLIDnego programowania. Wniosek był tylko jeden - błądzimy! ; )
Nawet najnowsza wersja jakiegokolwiek frameworka ma wsparcie na nie dłużej niż 2 lata, a aplikacje żyją często dłuuuugimi latami (osobiście spotkałem się z aplikacjami z PHP, które miały
nawet po 10 lat).

Zapominamy, że jedyną stałą w programowaniu jest "zmiana". Stary kod nie pozwala na korzystanie z nowszych parserów (no, tak nazwę interpretator PHP). Dlaczego jesteśmy tak
teraźniejsi? Dlaczego nasz wzrok sięga tak krótko w przyszłość? Często nie dalej niż termin oddania projektu. A później niech się dzieje co chce, niech klient samemu martwi się
nad tym co otrzyma - ktoś tam to przejmie, może komuś będzie chciało się przepisać kod na nowszy system...

To nie jest zbyt profesjonalne podejście. Powiedziałbym, że jest to zarodek tak zwanego "legacy code" - a z tym raczej chcemy walczyć.



Nie no, troszkę przesadziłeś. ; )

Dobrze wiesz, że chodziło mi o kod odpowiedzialny za wejście/wyjście, za I/O. Przecież podstawowa funkcjonalność frameworków składa się właśnie z tych dwóch rzeczy.
1. Wejście - framework odczytuje i przetwarza requesta, który tak naprawdę jest zwykłym stringiem! Tak, string, łańcuch znaków. Nic więcej. Zwykły Input (I z I/O).
2. Później po przetworzeniu tego stringa szykujemy odpowiedź dla klienta (Reponse), który także jest zwykłym stringiem. Zapomnijmy o przeglądarkach, zapomnijmy o
HTML-u i różnych zasadach ładowania plików CSS, JS itd, nieważne jaką stronę tworzymy, to przeglądarka otrzymuje najzwyklejszego w świecie stringa, który tylko dzięki znakom
"\n" wygląda jakby był czymś więcej - każdą stronę da się zapisać za pomoca jednej linii (czasem dłuuugiej) łańcucha znaków.

No i co najśmieszniejsze, - odkryłem to niedawno - frameworki kryją pod sobą tak naprawdę te dwa proste punkty, jednak z zewnątrz opisują swoje działanie w taki sposób,
jakby rozwiązywały ważne problemy z fizyki jądrowej. ; )

Nie odbierz mnie źle, ja procowałem na wielu frameworkach PHP, to moja codzienna praca, siedziałem na Zendzie, Symfony, Laravelu i kilku innych frameworkach, jednak
na swojej drodze spotkałem pewnego proroka, który otworzył mi oczy i pozwolił zrozumieć, że frameworki trzymają nas niepotrzebnie za jaja.

W końcu niezależność i przenośność to ważne punkty. "Coupling" to jeden z największych wrogów kodu. A frameworki wypchane są zachętami do "Couplingu", oczy programistów
zostały tak sprytnie zamydlone, że biedni nawet nie zauważają, że wprowadzają w swoje aplikacje swojego wroga nr 1, do tego wychwalają go - a on czeka na odpowiedni moment,
aby wbić nóż w plecy. Ale gdy się to zauważy, to jest już zdecydowanie za późno.

Ogólnie polecam to świeże spojrzenie. Zachęcam do medytacji nad prostotą działania frameworków i niepotrzebnego wiązania naszych aplikacji (taaak, kreślcie grube, czerwone linie pomiędzy
frameworkami a waszym kodem, który piszecie we frameworkach - frameworki to żadne szkielety, tylko diabelsko proste mechanizmy I/O) z frameworkami.

I pytam jeszcze raz - co jest takiego nadzwyczajnego w tym, że jeśli wyśle do farmeworka stringa "http://ksiazki.pl/przegladaj/Przygody-Jasia/", to on uruchomi mi kontroler "Przeglądaj" i wyśle argument
"Przygody Jasia"?

Czy w tym kontrolerze nie powinniśmy utworzyć instancji obiektu naszej aplikacji i przesłać argumentów typu "Przygody Jasia" i "przeglądaj"? Czy nasza aplikacja nie powinna także działać niezależnie
od frameworka, tj. po wysłaniu tych dwóch argumentów z linii poleceń, bezpośrednio do kodu naszej aplikacji, nie powinna zwrócić takich samych danych jak przy użyciu frameworka? Bo to wygląda
dla mnie jak niezależna aplikacja.

A jeśli korzystamy z jakiejś biblioteki farmeworka, to nie powinniśmy utworzyć "wrapperów" (adapterów?), które służą jako interfejs i oznaczają właśnie tą linię, w której framework komunikuje się
z naszą aplikacją? Czy aplikacja powinna wiedzieć cokolwiek o frameworku i bibliotekach jakie używamy?

Odpowiedzi na powyższe pytania pozostawiam do przemyślenia.

Ciężko się rozmawia gdy stosujesz pojęcia wg własnego "widzimisię".
Masz absolutną rację co do prostych zadań stawianych frameworkom i np. takim frameworkiem jest Symfony i tak był "reklamowany" (nie jako MVC tylko Request/Response).
Model niezależny od reszty aplikacji to też żadna nowość, wielokrotnie wspominane na forum. Symfony nie ma swojego modelu - to jest zadanie dla konkretnej aplikacji. Decoupling - czy nie dlatego powstał Symfony2?
Jeszcze tylko dodam, że ostatni LTS Symfony jest na 3 lata.


Zaczynam się skłaniać ku teorii, że karmię trolla.


Jeśli Twoja aplikacja jest tak prosta to możesz ją sobie zapisać nawet w jednym ifie.

Najpierw nie rozumiesz co oznacza słowo "aplikacja", trzeba Ci tłumaczyć jak krowie, że to kod pisany przez programistę (czyli wszystko oprócz kodu bibliotek i frameworka).
A że jeszcze nieopatrznie użyłem słowa "logika biznesowa", to oczywiście musiałeś zrobić to, czego się obawiałem, tj. powiązać to *jedynie* z modelem (z MVC), co zresztą
widać w Twoim komentarzu... (patrz niżej).





Tak, to już przerabiałem. W manualach Symfony autorzy rozpisują się o tym, jakie Symfony jest świetne, że jej wszystkie moduły to bundle, całkowicie niezależne.
Decoupling powiadasz... - tak, ale tego, że pisząc aplikację pod Symfony całkowicie uzależniasz się z tym frameworkiem, a także użytymi tam bibliotekami to już nie zauważyłeś.


Powiedz to programistom, którzy pracują na aplikacjach, które mają po 10+ lat. Jakby 3 lata to było dużo - to już nie jest nawet zabawne.



I widzisz, cały problem jest w tym, że ja pisze o decouplingu i przenośności, a jedyne co wyłapujesz, to słowo, tj. "prostota" - i dodatkowo w złym kontekście.



I na koniec udowadniasz, że powiedzenie "Gadaj z dupą to Cię osra" jest jak najbardziej na miejscu.

Także życzę miłego spotkania z ku..pą w majtach.