Ostatnio trafiłem na film z konferencji 4Developers z roku 2017, od tego czasu minęło trochę czasu i zmieniły się pewne rzeczy np. Symfony już nie jest taki ociężały jak wcześniej.

https://www.youtube.com/watch?v=7uzE2I3-iUk

Dlatego mam pytanie, czy zgadzacie się z autorem prezentacji dot. budowania serwisów bez frameworków (a raczej bez popularnych frameworków).

Wiele osób np. dla zwykłej prostej wizytówki internetowej instaluje wordpress tylko po to aby pokazać dwie strony: - główna i - kontakt.
Kiedyś firma na frameworku Symfony 1 zrobiła wizytówkę... strony szkolenia. Gdzie jedyną formą integracji z użytkownikiem był formularz zgłoszeniowy.

Takie przypadki nauczyły mnie że nie zawsze potrzeba używać zaawansowanego frameworka lub skomplikowanego CMSa aby stworzyć mały serwis.

od jakiegoś używam rozwiązania dla static html, które każdy możne sobie sam napisać w 2 dni, u mnie cały "framework" do tego to 3 pliki:
- ajax.php
- config.php
- staticPage.js -> to normalizuje wysyłane dane i w nim dopisuję obsługę formularza/y
całość wymaga podpięcia jQuery i dopisania pliku php dla obsługi akcji, walidacji danych i obsługi db, obsługuje metody GET i POST, często się zdarza że wysyła maile więc ma też możliwość podpięcia swiftmailer

takie jak moje wcale nie tak rzadko są używane a co najważniejsze postawienie lp przy gotowym html trwa chwilę

e:/ brakuje mikroframeworka stricte do obsługi ajax, przydała by się jakaś normalizacja w tym temacie

Co rozumiesz przez pojęcie "mikroframeworka stricte do obsługi ajax" ?

rozumiem to że będzie miał część zarówno backendową (php) jak i fontendową (js) którą sobie rozszerzasz do własnych potrzeb i będzie nastawiony na obsługę ajax

przy pomocy jego np szybko podepniesz działający kod pod formularz kontaktowy do lp etc.

Przeniosłem swojego bloga na Sculpin'a - polecam dla "stron wizytówek".

W pracy nasz projekt już dawno zdołał pożreć framework na którym został oparty i to pozwala nam dowolnie nim manipulować - dodać DI przez adnotacje, CQRS, circuit brekeara, warstwy domeny, infrastruktury, UI itp. Zafiksowanie się na framework, zwłaszcza jeśli projekt jest na lata, do niczego dobrego nie prowadzi. Z drugiej strony trzeba mieć ludzi którzy gdy zobaczą coś co nie jest frameworkiem i na naukę czego będą musieli poświęcić trochę czasu, nie uciekną z płaczem szukać innej pracy.

Obawiam się że w biznesie nie ma miejsca na takie sentymenty. Prosta stronka Single Page na Wordpressie i to ma być przerost formy nad treścią? Obawiam się że zrobienie Single Page fundamentalnie w HTML, CSS, JavaScript i PHP zajmie o niebo więcej czasu niż instalacja gotowych motywów do Wordpressa. A klient zawsze może sobie zażyczyć rozbudowę, ciekawe na ile się będzie opłacało klepać te stronki fundamentalnie?

Co do mniej popularnych frameworków, ktoś w ogóle dzisiaj jeszcze zaczyna jakiekolwiek projekty na Code Ignitherze, FuelPHP czy nawet Kohanie? Chyba tylko samodzielni freelancerzy bo inaczej to jest Symfony, Laravel i ich pochodne. W tym wideo chodzi o rzekomą degenerację umysłową jaką powodują frameworki, na podstawie Laravela to widać dobrze czasem na wykopie, nie mogę tylko znaleźć tego flame: "Piątek bez Laravela". Gdzie to w ogóle jest? Gdzieś na grupach Facebooka?

Ja w wielu kwestiach zgodzę się z przedstawionym materiałem. Ten owczy pęd za coraz bardziej skomplikowanymi frameworkami (mimo, ze maja w sobie mniej funkcjonalności!) wydaje mi sie być dyktowany pewną modą. Żeby być pro trzeba natrzaskac 15 klas, 8 interfejsów i dopiero wtedy wyświetlić jakiś tekst. Dalej: zależności pakietów composera. Ja wole wiedzieć co mam w projekcie, a nie dociągnąć różniste pakiety, ktore zależą od kolejnych itd. Swego czasu pisałem w Symfony, akurat wersji pierwszej, i faktycznie bardzo często spotykałem sie z „jak to zrobić w Symfony?”. Nie jak to zrobić, ale jak to ugryźć w konkretnym frameworku. Ileż to razy spotkałem sie z sytuacja „dodajmy do tabeli klucz główny id bo XXX nie wspiera kluczy złożonych” - wtf? mam dostosowywać schemat bazy do frameworka na którym pracuje?

Padło pytanie o Kohane: jeśli miałbym możliwość to wciąż bym jej używał. Aktualnie projekt przy którym pracuje stoi na ZF1. Da się? No pewnie ze sie da. Może w tych frameworkach nie ma DI czy innych wow wynalazków ale całość po prostu działa. I teraz każdy dostaje orgazmu na myśl o Symfony 3/4 ale za jakiś czas wyjdzie Symfony 7 i znowu będzie to „Best Symfony ever”. I tak w kółko.

Zwykle twórca stron dla klientów prywatnych czy także biznesowych robi ich wiele w swoim życiu zawodowym. Na tyle dużo, aby wiedzieć że większość klientów nie potrzebuje rozwijanych stron, a jeżeli potrzebuje, to decyzję podejmują zwykle po 5-10 latach. A jeżeli są jakieś zmiany, to są na tyle proste że nie potrzeba nawet edytora WYSWIG.
Dlatego uważam że Wordpress właśnie jest przerostem formy nad treścią. Przerostem, bo stworzenie oprawy graficznej dla mniejszego frameworka wcale nie jest więcej czasochłonne niż dla Wordpress.

Ja oczywiście nie neguję Wordpressa, bo na nim się dobrze pracuje. Ale wszystko zależy od projektu.

Jak to mówią - zależy...

Weźmy jako przykład proste strony wizytówki.
Jako, że od kilku lat nie robi się sekcji nowości (bo i tak w nikt ich nie uzupełniał), to strona może być w większości przypadków statyczna. Pojawia się pytanie czy napisać ją w od razu jako statyczną, czy skorzystać z jakiegoś FW i wygenerować do statycznej. Moim zdaniem lepiej wykorzystać jakiś generator stron, bo modyfikacje projektu jest dużo wygodniejsze. Ale takie zmiany musi robić programista, bo zwykły pracownik firmy sobie z nimi nie poradzi. Do prostych poprawek tekstowych można nauczyć korzystania z GitHuba i CI/CD załatwi resztę, no ale to też może być nie do przejścia. Poza tym budowanie całego systemu CD to raczej nie jest budżet małej strony wizytówki.
Co zatem zrobić, żeby klient sobie sam edytował stronę - CMS. Pomimo, że w wielu wypadkach będzie to przerost formy nad treścią, jednak rozwiązuje problem prostych aktualizacji strony przez klienta.

Aplikacje i frameworki.
Rzeczywiście ostatnio poszło w kierunku bycia bardziej pro. Nowoczesne podejścia, narzędzia, systemy testowania i budowania/dostarczania itd. Nawet proste aplikacje buduje się z dużym rozmachem (i często nadmiarem). To ma swoje plusy i minusy. Jeśli zna się dobrze platformę, narzędzia, framework - to praca z nimi jest łatwa i przyjemna. Problem jest tylko gdy się z tym wszystkim zaczyna, próg wejścia w programowanie jest obecnie duży wyższy niż kiedyś.
Z gotowymi narzędziami nie ma potrzeby wymyślania rozwiązań do popularnych zagadnień. Jednak większość projektów jest bardzo podobna, więc "zrąb aplikacji" może być ten sam. Korzystanie z popularnych, uznanych narzędzi przynosi się długofalowe plusy - łatwiej o pracowników, którzy znają dane rozwiązanie, zwykle duże projekty są długo utrzymywane, są wersje LTS, aktualizacje bezpieczeństwa itd. Minusem jest to, że trzeba się czasami dostosować do FW, bo czegoś się nie da zrobić, albo przyjęte jest robić w jakiś sposób.

Zostają jeszcze micro frameworki i komponenty. Które w wielu przypadkach są najlepszym rozwiązaniem - nie narzucają tylu rzeczy, a zapewniają rozwiązania najpopularniejszych zagadnień.

Jakiś czas temu wykonywałem integrację z nowym API inpostu.
Jako że jest to API restowe postanowiłem użyć Guzzle. Wszystko działało pięknie - to znaczy guzzle, a nie API - ale cały czas miałem wyrzuty sumienia że użyłem czegoś zbyt ciężkiego do tak prostego zastosowania.
Po chwili zastanowienia napisałem prostą funkcję która dawała mi praktycznie identyczne możliwości(w tym przypadku), a do tego była znacznie, ale to znacznie lżejsza.
Ba powiem więcej, ponieważ funkcja była dostosowania do tego konkretnego przypadku umożliwiała mi pisanie mniej kodu "na zewnątrz".
Moja funkcja to całe 30 linijek kodu i składa się tak na dobrą sprawę jedynie z czterech if'ów oraz kilku wywołań curl_*.

Ponieważ chwilowo nie mam dostępu do tych samych wywołań z użyciem guzzle posłużę się prostym przykładem z dokumentacji

[PHP] pobierz, plaintext 
$client = new \GuzzleHttp\Client();
$res = $client->request('GET', 'https://api.github.com/repos/guzzle/guzzle');
echo $res->getStatusCode()
[PHP] pobierz, plaintext 

Wygląda prosto, prawda ?
Tylko że ten prosty przykład wymaga includowania 29 plików, które łącznie mają około 6000 linijek kodu - liczone na szybko przy pomocy funkcji file_get_contents więc wynik jest zaburzony przez komentarze.

Moim zdaniem czasami warto poświęcić chwilę czasu i napisać coś własnego dla tego konkretnego przypadku niż użyć rozwiązania uniwersalnego które będzie miało znacząco większy narzut kodu.

I tak i nie.
Kiedys wychodzilem z podobnegego zalozenia co ty i generalnie wychodzilem z zalozenia, ze po grzyba mi te wszystkie molochy. Na szczescie pare lat temu przejrzalem na oczy i zaczalem w koncu zarabiac konkretnie No ale nie o tym chcialem.
Guzzle to warstwa abrakcji. Dzieki Guzzle mozesz pobierac dane z innych serwisow nawet jak jakims cudem nie masz curl. Tak, domyslnie Guzzle korzysta z curl ale mozesz tam tez uzywac innych rzeczy, jesli z jakiegos powodu curl nie posiadasz.
W twojej klasie, gdyby pojawila sie taka sytuacja, trzeba by znowu zmieniac kod.
Guzzle daje tez inne rzeczy, jak polaczenia asynchroniczne.
Guzzle mozna mockowac i tworzyc ladne testy.
Argument o ilus tam liniach? Jestes pewien ze laduje on naprawde te wszystkie 29 plikow i 6tys linii? To, ze caly projekt tyle ma, nie znaczy ze w danej chwili tyle laduje.
Raz sie nauczysz Guzzle i uzywasz wszedzie. Przyjdzie nowa osoba do zespolu, widzi Guzzle i wie jak uzywac. Widzi twoja klase i musi sie zastanawiac a jak, a po co, a jakby chciec cos innego to co wtedy. a jak nie daj boze nie ma tej funkcjonalnosc co byla w guzzle to trzeba teraz przerabiac twoj kod bo akurat o czyms niepomyslales a nagle potrzebne.

Podsumowujac: zabawa we wlasne rzeczy jest ok gdy sie pracuje samemu i ma sie gleboko gdzies bycie w miare na biezaco. Jak juz pisalem, kiedys tak robilem, ale na szczescie sie otrzasnalem z tego stanu.
I jak juz wspomniano: tak, czasami (a nawet czesciej niz czasami) wykorzystuje sie mala czesc danego rozwiazania. Ale oszczedza sie duzo czasu co nie raz jest wazniejsze. A co bardziej kumaci to tak dobieraja FW by spelnial ich oczekiwania i zamiast jakiejs kobyly wezma poprostu micro FW bo akurat do banalnego API on bedzie najlepszy.

Gotowe rozwiazania sa przetestowane przez autora i przez spolecznosc. Nawet jak pojawi sie jakis bug, to jest on naprawiany przez autora i ty nie marnujesz na to czasu. We wlasnych rozwiazaniach, ktore sa tez z reguly zamkniete, to ty musisz wszystkiego pilnowac a i tak nie dopilnujesz wszytkiego a potem luki krytyczne w systemie.

Tak jestem pewien że ładuje te 29 plików ponieważ sprawdziłem to w najprostszy możliwy sposób, dodałem var_dump($file) przed include autoloadrea ;p
Oczywiście należy brać pod uwagę że część tych plików jest wykorzystywana przez inne komponenty.

Tak zdaję sobie sprawę że ma on znacznie większe możliwości ALE w tym konkretnym przypadku ich nie potrzebowałem.
Wywołanie guzzle w przypadku tego API ogranicza się do wybrania czy ma to być GET czy POST, wskazania adresu, modyfikacji nagłówka(autoryzacja) i ewentualnego przesłania danych.
Czyli w moim przypadku można powiedzieć że różnica wygląda w taki sposób że zamiast tego

[PHP] pobierz, plaintext 
$client = new GuzzleHttp\Client();
$res = $client->request('POST', 'https://..../AKCJA', [jakieś dane, 'headers'  => [nagłówek do autoryzacji]]);
[PHP] pobierz, plaintext 

trzeba zrobić

[PHP] pobierz, plaintext 
$apiInpost = new Inpost();
$res = $apiInpost->request('POST', 'AKCJA', [jakieś dane]);
[PHP] pobierz, plaintext 

Tak jak pisałem jest do dostosowane do tej konkretnej sytuacji, API firm kurierskich raczej nie zmieniają się często. A nawet jeśli taka sytuacja wystąpi to i tak musiałbym zmieniać kod napisany z użyciem guzzle.
Myślę że każdy średnio rozgarnięty orangutan poradzi sobie ze zrozumieniem o co w tym chodzi.


Oczywiście nie chcę powiedzieć że gotowe rozwiązania są złe i zawsze trzeba wynajdywać koło na nowo.
Ale czasami warto się zastanowić czy własne rozwiązanie nie będzie lepsze ?
Może zamiast zaawansowanego komponentu do filtrowania danych wystarczy zwykły foreach i if ?
Czy na pewno potrzebujemy kombajnu tylko po to żeby skosić trawnik?
Dobrze przemyślane własne rozwiązanie może być zrozumiałe dla innych tak samo jak to ogólnodostępne.

Guzzle jest chyba tylko opcjonalne, nie wiem jak jest w Laravelu ale np. analizując dokumentację Symfony:
https://symfony.com/doc/current/components/browser_kit.html

wychodzi że wszystko jest wbudowane i można wykorzystywać standardowe komponenty. W Kohanie też wcale nie jest z tym tak źle:
https://docs.koseven.ga/guide/kohana/requests

I też można by się zastanawiać nad celem użycia Guzzle, bo nawet w przypadku braku rozszerzenia php_curl (nie spotkałem się jeszcze żeby to nie było dostępne nawet na darmowych hostingach), to w bootstrap.php można sobie ustawić domyślnego klienta np. Stream zamiast Curl.

FuelPHP też ma widzę podobne założenia:
https://fuelphp.com/docs/general/hmvc.html

@sazian az sprawdzilem te liczbe klas w Guzzle. No mi zaladowalo 22 klasy co nie zmienia faktu, ze tez duzo. Z drugiej jednak strony jak mi projekt SF4 w tym samym czasie laduje 400 klas to te 22 to kropla w morzu
Teraz z php7 nie ma co sie za bardzo szczypac. Zwiekszyli ladnie wydajnosc i nawet nie odczujesz tych dodatkowych 22 klas a zaoszczedzony czas na niepisanie nowego wlasnego rozwiazania moze byc cenny.

Choc moze w niektorych przypadkach jest jak mowisz. Ale trzeba umiec wysrodkowac to by sie nie skonczylo, ze ktos potem pisze wszystko na wlasna reke

Jeśli mówimy o Guzzle to on ma te jedna zaletę, że używa PSR-7, którego zapewne Ty nie wspierasz.

Dla mnie to jest raczej próba wywołania dyskusji o frameworkach i o kierunku, w którym to wszystko ma podążać.
Bo na zdrowy rozum: jaka jest alternatywa dla popularnego frameworka?
Tylko własny framework - a przecież własny framework ma dokładnie te same wady, o których wspomina autor, tylko należałoby je pomnożyć razy dwa:
- dołączenie do zespołu np. symfony vs framework Ziutka, kto teraz będzie bardziej błądził?
- ok, nie podoba mi się bundle do oAUTH to go zmieniam na 20 innych lub piszę własny - a framework Ziutka? Klniesz czy krzyczysz?
- za to framework Ziutka to ma super dokumentację, no ale przecież każdy powie, że najlepsza dokumentacja to czysty kod
- za to framework Ziutka sam w magiczny sposób niedawno obsługuje Bootstrapa 4 - a przepraszam, planujemy za dwa lata odejść od PHP 4, ale na razie nie ma kasy na refaktoryzację
- za to framework Ziutka z dnia na dzień coraz szybszy
- nie to co we frameworku Ziutka, wystarczy wszędzie używać mysql_escape
- tak, u Ziutka nie ma tych problemów bo tu wszystko zależy od wszystkiego

Następne "Programista frameworka" to wypisz wymaluj moje problemy z apkami "bez frameworka"
- nie mogłem użyć standardów, bo fw Ziutka
- spędziłem dni wertując kod, zamiast godzin wertując dokumentację
- zamiast zamęczać staka zakłócałem spokojną starość twórców Ziutka
- coś co nie jest w bundlu nie istnieje - zgadza się, zamiast w 15 minut dociągnąć bundla musiałem siedzieć tydzień albo powiedzieć biznesowi, że się nie da lub za droga
- rozwiązuje problemy stwarzane przez framework - o to to to, za to Ziutek wolny od bugów, elastyczny, wszystko logiczne i intuicyjne
- wierzy, że reszta świata się myli - nie to co twórcy Ziutka upierający się przy swoich rozwiązaniach

@Pilsener widze ze ten "Ziutek" zalazl ci niezle za skore

@Pilsener
Nie wiem dlaczego wszystko sprowadzasz do tego jakby twórca aplikacji bez znanego lub własnego framework był totalnym imbecylem informatycznym.



Nie chce bronić twojego Ziutka, ale...
ad a)
Aplikacje na starych frameworkach też mają trudności z użyciem standardów.

ad B)
W dokumentacji też nie musi być wszystkiego. Dokumentacje Symfony, Laravel etc nie są idealne. Dotyczą podstaw. Gdy dodasz własne rozwiązania, klasy, funkcje nie koniecznie będą wpisane do dokumentacji.

ad c)
Jak znam życie, Ziutki nie pamiętają tego co napisali.

ad d)
Cóż... albo wykorzystujesz pracę innych, albo wytężasz bardziej swój umysł.

ad e)
Nic nie jest wolne od bugów, w tym przypadku na korzyść frameworków przemawia że są szybciej wyłapywane, ale nie koniecznie równie szybko dostaniemy nową wersję.
Ziutkowy system naprawy bugów, może wyłapany błąd naprawić od razu (przy okazji tworząc dwa inne które zostaną odkryte w późniejszym czasie)

ad f)
To tak jak ktoś buduje dom 10 lat, potem przychodzi jakaś moda albo lepsza technologia która pozwala budować domy które po wybudowaniu będą tańsze w eksploatacji.
Ale ile osób pozwoli sobie zburzyć ten swój dom z cegiel w który wrąbali mnóstwo oszczędności, energii czy też emocji. Tylko po to aby zacząć budować coś od nowa?
Szczególnie jeżeli nie ma się dodatkowego wsparcia, który przyśpieszyłoby ten proces.

- hehe, bo to tak zwana "pułapka własnych rozwiązań", kto kiedyś babrał się w takich projektach ten zna to doskonale z autopsji, najgorsze że te same problemy ciągle wracają i czasem mam stracha, że na stend apie ktoś wypali "no to piszemy własny ORM, będzie idealnie dopasowany do naszych potrzeb, napiszemy go w tydzień i będzie lepszy od Doctrine"

- oczywiście, ale przenieść apkę np. z Zend 1 na 2 jest o niebo prościej i czasem można nawet spotkać gotowe narzędzia do migracji, dużo prościej też radzić sobie z tego typu problemami (można liczyć np. na jakieś adaptery)

- to oczywiste, jednak nie wierzę, że każdy pisze dokumentację na poziomie komponentów z Symfony

- haha, prawda, jednak tonący brzytwy się chwyta, sam dostaję do dzisiaj maile typu "Hej, podobno robiłeś kiedyś przy fw Ziutka, możesz mi pomóc w .... " - czasem coś pamiętam a czasem nie

- ile razy mam pisać error handler, router, navigation & breadcrumb czy inne takie? Akurat niedawno zdarzyło mi się pisać i wzorowałem się na Symfony Po co wynajdywać koło na nowo? I jak bardzo trzeba wytężyć swój umysł przez np. miesiąc (deadline!), żeby dorównać 1500 kontrybutorom Symfony razy parę lat? Są rozwiązania przemyślane, oklepane, sprawdzone, otestowane, udokumentowane, łatwe w użyciu - po co to zmieniać? I chciałbym wiedzieć, jak ktoś przekona do tego stronę biznesową

- prawda, wobec bugów w komponentach jesteśmy często bezradni - zdarzało się forkować, w Ziutku wystarczyło trochę "pomęczyć" kogo trzeba i można było wydać pacza w tydzień, no ale trudno, żeby coś było całkiem wolne od zalet

- tak, im więcej czasu i pieniędzy ktoś zainwestuje tym mniej chętniej z tego rezygnuje. Jednak w IT mamy ten problem, że sytuacja tu się zmienia dość dynamicznie a programista jest między kowadłem zmieniających się ciągle technologii a młotem sprzecznych czy absurdalnych wymagań biznesowych - dlatego lepiej nie przywiązywać się do kodu, zwłaszcza swojego

że wam chce się dyskutować... jeśli nie jesteś molochem którego stać i który musi szukać niestandardowych rozwiązań, to fw zawsze będą lepsze i koniec kropka - po to zostały one stworzone. Samodzielne pisanie fw jest dobre tylko do nauki, na pewno nie do robienia biznesu w typowej skali. A jeśli już ktoś poczuwa się do takich ambicji, to wrócę do wcześniej wspomnianego "domu", rozumiem że cement rozrabiany był pewnie ręką w wiadrze bo po komu betoniarka.

Nie zapomnij o kopaniu gołymi rękoma pod fundamenty. Chyba że dorzucisz jakieś nietypowe rozwiązanie typu łopatograbiowidły bo trzeba było zrobić coś uniwersalnego

Ale właśnie to duże fw to łopato-grabio-widły-z-pilotem-do-koparko-spycharki mimo że potrzebna jest tylko łopata i szpadel

Właśnie pracuję na takim home-made-fw. Autor zarzeka się że daje on mu elastyczność. W praktyce nie da się prosto wprowadzić jakiejś funkcjonalności i tam gdzie trzeba coś lekko zmienić pojawia się metoda1, metoda2, metoda3. Do tego wszystkie zapytania przechodzą przez pdo->query zamiast prepared statements, brak jest obsługi transakcji, zero namespace, zero wyjątków. Debugowanie to echo $this->debug .= ''; Działa na tym jedna z większych firm w Polsce a autor na wszystkie słowa "unowocześnienie", "interface", "di" reaguje alergicznie "bo to zwiększy narzut na naukę". Co jest kpiną bo dokumentacji żadnej nie ma. Pewnie chodzi o to żeby go nie zwolnili. Tylko on ogarnia co się dzieje.

Znam kilku takich "twurcuf" FW.... I tak... w pewnym senisie taki to się ustawi

Tyle że w przypadku dużych fw zazwyczaj sie da (przynajmnie powinno się dać ) wybrać tylko to co potrzebne, potrzebujesz koparki, bierzesz i używasz koparki, potrzebujesz wideł, bierzesz widły. A we "frameworkach" masz na chwile łopatą do śniegu wykopać dól bo nie było czasu nad utworzeniem normalnej łopaty albo łopata się łamie

Ogólnie rzecz ujmując, należy zawsze brać narzędzie potrzebne do wykonywanej pracy, czasem lepiej "napisać" sobie prostą łopatę niż brać koparkę do wykopania dołka pod jednego kwiatka

Grunt to nie wybierać się z motyką na słońce

- w hydeparku zawsze

- hehe, mi się też właśnie taki projekt trafił, zaczynam od error handlera, który rozszerza klasę bazy danych a ta z kolei rozszerza główny kontroler - wyświetla błędy w stylu "błąd w zapytaniu select * from tabela" i ani nic w logach, ani stack trace, ani nawet w którym pliku - domyśl się. Klikam na nazwę klasy, ale IDE nie potrafi powiedzieć gdzie jest jej definicja, bo nazwy plików są inne niż nazwy klas a ładowanie klas jest dynamiczne na podstawie parametrów z URL.
Zapowiada się niezła zabawa.