Forum PHP.pl

Witam jaśnie wielmożnych formumowiczów.

Mam do was pytanie, bo tak się zdarzyło, że od pewnego czasu piszę (jednocześnie ucząc się) symfony2. Moje pierwsze wrażenie, to "ależ to kobyła". Z moich obserwacji wynika, że używa się go głównie do dużych projektów, i to takich które są pisane pod jedną konkretnę stronę. Takie joomle czy wordpressy albo phpbb czy vBulletin nie są napisane w żadnym fw (jeśli się mylę, to poprawcie).

Kieruję do was pytanie: kiedy właściwie należy użyć framerowka, a kiedy nie? A może do tych mniejszych projektów należy użyć mniejszych fw ?

Jeśli dubluję temat, to najmnocniej przepraszam i proszę o linki (IMG:style_emoticons/default/tongue.gif)

Na tle innych - niekoniecznie PHP-owych - frameworków Symfony wcale jakiś strasznie kobylasty nie jest.
Większość z nich powstała jeszcze przed "erą frameworków PHP". Ale z tego co kojarzę phpBB4 ma działać w oparciu właśnie o Symfony2.
Jeżeli narzędzie (tutaj: framework) w ogóle nadaje się oraz pomoże w szybszym/łatwiejszym/lepszym/tańszym wykonaniu docelowego zadania to powinno się z niego korzystać.
Nie, nie należy. W czym przeszkadza użycie "dużego" (bardzo dziwna klasyfikacja swoją drogą) frameworka przy małym projekcie?

Też się uczę właśnie Symfony2 i w sumie mogę przyłączyć się do pytania i od siebie coś dodać:

Z tego co mi wiadomo, to nie jest powiedziane, że Symfony2 - Duży FW, nadaje się tylko do dużych projektów, lecz również ma zastosowanie w mniejszych projektach/stronach, np niech sobie będzie strona, która zawiera w sobie 4 podstrony (Home, Gallery, AboutUs, Contact) i myślę, że śmiało może być ona napisana w Symfony2, oczywiście nie będziemy pod nią tworzyć 10 kontrolerów, 100 widoków, wielkiej bazy danych itd, ale nawet jeśli wykorzystujemy jeden kontroler, 4 widoki, 1 base view, a do tego dodatkowo pomocne widoki, które np pokazują nam duże zdjęcie w galerii to i tak Symfony2 się do tego nada.

Nie ma podziału na duży i mały FW.
Do każdego projektu nadaje się FW nie ważne czy to jest Kohana czy Zend czy Symfony2, wszystko zależy od umiejętności programisty. Zend jest zbiorem wielu klas więc każdą z nich wykorzystać osobno w innym FW.

To że ktoś mówi że Symfony2 nie nadaje sie do małych projektów, a Kohana nie nadaje sie do dużych jest głupcem, bo w większości przypadków ta osoba nie potrafi podać jednego sensownego powodu dla którego dany FW nie sprawdzi się przy określonej aplikacji.

Sumując. FW zawsze i w każdej aplikacji.

Znajomy mi napisał, że mały projekt zadziała z dużym FW, ale jest wtedy ładowane mnóstwo niepotrzebnych danych, uruchamia się wtedy cały fw...

"To tak jakbyś uruchomił kombajn do skoszenia trawnika"

Co o tym możecie powiedzieć ?

@Szymciosek: Przede wszystkim co z tego, że wiele niepotrzebnych rzeczy może się uruchomić?

Przy małym projekcie w większości przypadków nawet nie warto będzie bawić się w konfigurację FW celem ich wyłączenia.

Ten post edytował Crozin 29.08.2012, 15:19:39

Ważne jest aby wybrać narzędzie które najlepiej będzie pasowało do danego zadania.

Konsultując się dalej ze znajomym, twierdzi że niepotrzebnie jest obciążany serwer niepotrzebną ilością danych.



Czyli wg Ciebie jest warto bawić się w wyłączenie np Doctrine, jeśli z niego nie korzystam ? Za to Crozin zaś twierdzi, że nie warto się bawić w to przy małym projekcie.

Ten post edytował Szymciosek 29.08.2012, 15:25:44

jak sobie do symfony2 dodałem pare bundli to wyszło mi, że cały folder ma ponad 100mb. Wrzucanie tego na ftp mi się niezbyt podoba :/

Oczywiście, że każda dodatkowa, zbędna operacja to jakieś tam zwiększenie obciążenia serwera, ale:
1. Przy małych projektach to dodatkowe obciążanie jest nieodczuwalne. Co za różnica czy strona wygeneruje się w 0.018 czy 0.02 sekundy? Co za różnica czy jakieś dodatkowe śmieci się tam robią, skoro serwer jest jeszcze wstanie obsłużyć 2, 5 czy 25 razy większy ruch w "komfortowym" czasie?
2. Jak zaczynają pojawiać się problemy z wydajnością to wprowadza się jakieś podstawowe poprawki optymalizacyjne - wyłącza co niepotrzebne, zwiększa się ilość rzeczy lądujących w różnego rodzaju cache (przetworzone dane biznesowe, akceleratory PHP, reverse-cache itp.). Jeżeli nadal istnieją problemy z wydajnością przenosi się na mocniejszą maszynę - bo jest to zazwyczaj śmiesznie tanie rozwiązanie. Dopiero ostatnim krokiem jest babranie się z dziesiątkami drobnych optymalizacji.
3. Jeżeli ideologicznie przeszkadza Ci wykonywanie przez serwer zbędnych operacji zapomnij w ogóle o PHP. Język sam w sobie jest powolny, a i środowisko w jakim pracuje (żądanie -> władowanie wszystkiego -> wykonanie kodu -> odpowiedź -> zakończenie procesu) nie sprzyja optymalnemu kodowi.

Oczywiście, jeżeli jakaś tam optymalizacja jest łatwa do wdrożenia, np. wyłączenie całego Doctrine'a w Symfony2 to usunięcie dwóch linijek z AppKernel.php/autoloader.php, to powinno się to zrobić już na etapie tworzenia projektu.

Zacznijmy od tego, że na serwer nie wrzuca się całych repozytoriów GIT-a, bo to one tyle zajmują. Zresztą kod bibliotek (3rd-party-code) możesz pobrać sobie już na serwerze, po co wrzucać to przez FTP.

Ten post edytował Crozin 29.08.2012, 15:55:37

Parę bundle za pomocą git i

to wiedz, że foldery git będą zajmowały właśnie tak dużo ze względu na to, że zawierają kompletną historię każdego pakietu...
Możesz to łatwo usunąć za pomocą komendy:

Jeśli chodzi o Joomle, to została napisana w swoim własnym frameworku (który nawet nie jest wydzielony od właściwego CMSa). Takie specyficzne rozwiązanie, ale pod Joomle wszystko się pisze zgodnie z konwencją tego frameworka.

kiedy używać?
kiedy tylko można:P
wg. świetny framework, ogromne comunity, całą masa bundli gotowych, nie trzeba pisać czegoś po raz n-ty
wrzucanie na ftp to najciekawszych zajęc nie należy ale podobnie jest w przypadku innych fw.
Ja polecam!

W przypadku innych fw to wgrywasz ~300KB, dodajesz w configu dane bazy i możesz już tworzyć (IMG:style_emoticons/default/wink.gif)
Oczywiście inne, mniejsze fw nie dadzą ci w standardzie generatora kodów kreskowych itd. Ale jak często robiąc stronę firmy, prywatnej osoby czy jakiś cms lub crm a nawet gierkę musisz generować takie cuda? Większość aplikacji to crudy + modele przetwarzające jakieś dane, a w tego typu aplikacjach każdy fw jest ok jeśli pisze ci się w nim szybko i wygodnie. Większy fw warto wybrać jeśli wiemy że to co piszemy będzie rozwijane przez kolejne x lat i wszystko może się tam pojawić. Ale nawet w takim wypadku zawsze można wtedy dograć odpowiednią bibliotekę której akurat fw nam nie dostarczył.

niestety jako fanboy symfony mam inne zdanie : D

Podziel się (IMG:style_emoticons/default/wink.gif)

Jak juz ktos wspomnial nikt na serwer nie wrzuca caelgo projektu symfony2 raz z bundlami i assets.
Wgrywamy tylko nasza aplikacje a reszte bundli instalujemy przez vendors.

Ja aktualnie jestem na praktykach jako mlodszy programista PHP pisze w SYmfony2 i musze powiedziec ze moze sie nadawac do wszystkiego czemu nie (IMG:style_emoticons/default/wink.gif)
Jego opanowanie zajmuje jakis miesiac przynajmniej dla mnie, jest masa plikow/katalogow.
Jest do poznania Doctrine(bo propel jest jakis glupawy),twig i kilka innych.

Ja polecam choc malo znam to mnie sie podoba

Aplikacje czyli co ? Jakie foldery/pliki ? Również zaczynam przygodę z Symfony2
Jeszcze mam takie pytanie dotyczące vendors, na pewnej stronie wyczytałem, że podczas ich aktualizacji do nowszej wersji możemy być zdziwieni, gdy projekt przestanie działać (to tyczy się composera). I tu pytanie, skąd mam wiedzieć co mogę/warto aktualizować, a co jest ryzykowne ?

Czytajac changelog bundli czy sa jakies wiekszy zmiany w API/konfiguracji/bazie

Dodajesz tylko twoje pliki do projektu bez zadnych bundli ktore sa ci potrzebne do dzialania aplikacji.
Czyli bez doctrine,twig-a itp..itd..
Potem ktos sciaga twoja aplikacji i za pomoca vendors instaluje wszystkie brakujace moduly ktore masz opisane w deps/deps.lock

No tak, w przypadku aplikacji, które są dostępne dla innych to się zgodzę, że zbędne jest wrzucanie folderu vendors do całej paczki, ale gdy projekt ma być online (np strona internetowa), to wtedy powinny być wszystkie foldery, albo całe vendors umieszczone np w usr/share.