Wynajdywanie koła to ryzyko.
Może się trafić takie...
Wiedziałem, że tak będzie. Wiedziałem, że nie będę spokojny, kiedy nie jestem z czegoś do końca zadowolony. Szukałem frameworka, który udostępni mi sposób budowania aplikacji taki, jaki mi się marzy. Żaden do tej pory nie stał się dla mnie wzorem. Symfony jest najbliżej, ale po prostu czuję jej ciężar. To taki TIR z dwoma przyczepami, a Ja szukam busa. Mój projekcik w warstwie kontroli to najbardziej rozbudowany (choć nieukończony) szkielet. Posiada nawet zaawansowany język przepływu sterowania napisany w XML. Jak się uprę, to jego moduły mogą służyć za modele! Mimo to wydaje mi się źle napisany, a do tego, którymś momencie zgubiłem ideę. Kluczowym momentem była obsługa modułu (wirtualny kontroler), której kod okazał się tak bezwładny, że aż mi się nie chciało go rozbudowywać. Załatałem tylko jak popadnie. To wszystko zniechęciło mnie tak skutecznie, że pomysł udostępnienia źródeł wydaje mi się czymś zabawnym, jeśli nie groteskowym.
Wczoraj oglądając kod Kohany myślałem, aby go rozszerzyć - zrobić prywatny fork projektu. Gdy rozejrzałem się jeszcze troszkę, to wogóle zrezygnowałem z robienia czegokolwiek na tym szkielecie. Wyszło na to, że jakbym dopisał do własnego FW jakieś ładne walidatory, i jakiś generator formularzy, to bym miał trzy razy bardziej zaawansowaną konstrukcję. Po kiego diabła mam ruszać kod, który wydaje mi się biedny i go rozwijać? Lepiej, jeśli przepiszę K.V.K. Z przepisywania zrobiło się pisanie niemal od nowa, choć po pierwszym dniu jestem już na etapie implementacji Front Controllera.
...choć równie dobrze takie...
Może za tydzień uda mi się uruchomić przynajmniej część. Mam sporo roboty z innym projektem, więc pewnie moje założenia są nadto optymistyczne. Cóż. Zobaczymy bo nie zaczynam zupełnie od nowa, a jedynie zmieniam implementację przemyślanych wcześniej funkcji. Bardzo poważnie zastanawiam się nad podwójną obsługą kontrolerów. W przeciwieństwie do np. Kohana,
czy Symfony nie posiadam akcji jako metod, tylko jako obiekty. Rozwiązanie jest dobre, choć czasami zbędne. Miałem już ochotę w pewnym momencie upchnąć akcje w jeden kontroler, ale nie chciałem zmieniać radykalnie koncepcji. Teraz mogę elegancko zaimplementować oba rozwiązania i zapewne tak zrobię. Pomysły mam, to najważniejsze.
Tak samo nie rozumiem czemu ludzie pisza walidatory do kontrolera, jak mozna walidowac dane po stronie modelu...
Zycze ci udanego refaktoringu i obys chcial dzielic sie swym kodem ;)
To, że akcje są w metodach to tylko dlatego aby ułatwić to o czym wyżej pisze sfhx.
Jednak uważam, że jego podejście nie sprawdza się zawsze, akcje się różnią. Przykładem mogą być metody preExecution i postExecution, korzystanie z nich w jednej akcji, mogłoby zakłucać inną akcje. Oczywiście symfony po raz kolejny daje programiście wybór, korzystasz jak potrzebujesz lub jak Ci wygodniej.
Symfony jest ciężkie, ale spokojnie, dwie przyczepy to jeszcze nic, a przy tym jaka funkcjonalność i użyteczność. Oby tylko z Twojego KvK nie wyszedł ciężarem roadtrain a użytecznością riksza :P
Symfony układa akcje na stosie: sfActionStack.
Za akcję uważam działanie w ramach logiki biznesowej. Przykładem jest np. dodanie rekordu do tabeli. Oczywiście akcja może zrobić to za pośrednictwem modelu, lub w prostu w swoim ciele (to nie jest tutaj istotne). To, że układa na stosie obiekty sfAction, nie znaczy, że każdy z nich opowiada jednemu poleceniu. Są to jedynie instancje, na rzecz których wywołano jedną z ich wielu metod executeXXX. To, co proponuję, to tożsamość dla każdego polecenia. To w Symfony jest emulowane. Nie mówię, że to źle, nawet uważam, że taki kompromis jest w wielu przypadkach lepszy.
Może kiedyś ;)
1. Brak czegoś takiego jak widok(View) mamy akcje która wywołuje kontroler. Więc do osługi kilku widoków robimy kilka metod w akcji ;) Litości...
2. Walidacja formularzy, tutaj można zapomnieć o czymś takim jak zależności pomiędzy walidatorami. W ogóle praca z tymi walidatorami symfony jest dość toporna.
3.Helpery...większość z nich to jedno wielkie nic. Na pewno nie pomaga przy szybszym wdrożeniu aplikacji a co najwyżej wprowadza zamieszanie.
4. Funkcje O.o Tak nie ma obiektu dla języków jest __(), link_to etc. ;)
Więc ogólnie rzecz biorąc w Mojej bardzo subiektywnej ocenie mogę powiedzieć że prywatnie nigdy bym tego frameworka nie użył.
Ad 1. Tak to już jest w MVC, że akcja wywołuje kontroler (chyba, że nie wiem o czymś). Nie ma widoku? Bez przesady, jest. Z widokami i z akcjami też nieźle namieszałeś, nie jest tak jak piszesz.
Ad 2. No prawie masz racje, tylko powiedz, który framework wspierał zależności między walidatorami. A toporność to pojęcie względne.
Ad 3. Ciekawe co Twoim zdaniem powinny robić helpery...
Ad 4. Znowu się nie doczytało. __() to właśnie ten nieprzydatny helper. Jest obiekt do języków (sfI18N). Autorzy i nie tylko oni wyszli z założenia, że w szablonie lepiej użyć: __('tłumacz') niż: sfContext()::getInstance()->getI18N()->__('tłumacz')