Właśnie spróbowałem, tak pisze się łatwo, bo kod samego filtra nie jest jakiś skomplikowany. Ale aby ładnie zintegrować swój filter (w moim przypadku odpowiedzialny za filtrowanie danych wejściowych w requeście) trzeba było napisać też do tego ConfigHendlera (aby dane na temat filtrów były pobierane z nowego pliku konfiguracyjnego osobnego dla każdej akcji) oraz rozgryść z czym to się je, a dojście do tego od zera jest trochę bardziej trudne

Dzięki za naprowadzenie na rozwiązanie.

Wybór padł - Wziąłem się na poważnie za Symfony. Jest na prawdę dobrze opisany językiem dla początkującyh na stronie projektu: przystępnie ale nie prymitywnie. Po przerobieniu kilku pierwszych chapterów poradnika ( http://www.symfony-project.org/book/1_2/01...oducing-Symfony ) można już zrobić pierwsze działające konstrukcje ( w sf_sandbox )

Jasne jest że jeszcze prawie nic o tym frameworku nie wiem ale o jego dokumentacji i wsparciu mogę powiedzieć że są na prawdę dobre, żeby nie powiedzieć najlepsze (najprzystępniejsze) z tych, z jakimi się spotkałem w swojej krótkiej frameworkowej karierze.

Materiały oczywiście po angielsku.

Nie tylko.
http://trac.symfony-project.com/wiki/Docum.../pl_PL/book/1.0

a jak sie ma wykorzystywanie frameworkow do projektow komercyjnych? trzeba za to placic czy mozna korzystac zupelnie za darmo?

Nie trzeba płacić. Ale nie możesz brać kasy za sam framework, możesz brać tylko za aplikację napisaną za jego pomocą.

Niedługo mam zamiar skorzystać z jakiegoś FrameWorka, jakiego polecacie na początek?

Jaja sobie robisz? W wątku na temat wyboru frameworka po 50 postach piszesz co Ci polecamy?
Rusz dupsko i przeczytaj to co zostało już napisane!

@mike, faktycznie- zapomniałem przejrzeć poprzednie strony. :-)

Pragmatycznie porównanie Zend Framework, Symfony i CakePHP zrobione przez ludzi z IBM:
http://www.ibm.com/developerworks/library/...ex.html?ca=drs-

Jest jeszcze framework PRADO (http://www.pradosoft.com/) - jest on wzorowany na ASP.NET, więc jeżeli ktoś go zna to się poczuje prawie jak u siebie w domu. Strona jest po angielsku, ale Wiki (a przynajmniej część) jest przetłumaczona na Polski. Polecam też obejrzeć Blog Tutorial znajdujący się w sekcji Documentation - jest to przykład jak wykorzystując PRADO zbudować prostego bloga.

A bawił się ktoś Akelos Że najbardziej RoRowy ponoć.

taki mały OT

A jakie masz stanowisko, co do tego powyżej. Bo dla mnie bzdury... rubbish!

Ja w swojej "karierze" przerobiłem 3 frameworki:
- Zend Framework - w wersji 0.7
- CI
- Symfony

O pierwszym zostało już wszystko powiedziane. Potężny zbiór klas, ale nie framework. Często korzystam z samych klas, ale jako framework nie jest to dla mnie wygodne rozwiązanie. Plus za dokumentację.

CI - bardzo wygodny był przy małych projektach. Szalenie szybko się w tym pisało - podstawy frameworka można było opanować w kilka godzin. Bardzo dobra (w sensie przystępności) dokumentacja. Minus to php4 i "ubogość". Dla mnie raczej był to szkielet frameworka. Sposób napisania frameworka sprawiał, że dokonywanie zmian wymagało "niebezpiecznych" zagrań, które mogły się zemścić w innych miejscahc - wiadomo globale itp.

Symfony - miłość od 2 wejrzenia. Za pierwszym razem coś nie chciało się zainstalować i szybko się poddałem. Wróciłem po jakimś czasie i się zakochałem ;-). Główne plusy:
- bardzo dobra dokumentacja zarówno "książka" jak i api
- framework obiektowy, więc modyfikacje są bardzo proste i wygodne
- świetny system konfiguracji - na początku wydaje się nie do ogarnięcia, ale po przeczytaniu odpowiedniego rozdziału książki wszystko robi się dziecinnie proste
- konfigurowalne środowiska - 2 liniijki i masz wersję aplikacji, która działa z cache albo bez, która wyświetla błędy dla programisty albo nie itd itp.
- debugtolbar - świetna sprawa - widzisz ile czasu trwało żądanie, ile i jakie zapytania poszły do bazy, co ile trwało, wszystkie logi i zmienne requesta w jednym miejscu - jednym słowem proste debugowanie
- doskonały system cache - kilka linijek konfiguracji i można cachować całe strony lub ich części odciążając serwer. Cache jest kilkustopniowy i można go bardzo ładnie dostosować do konkretnych potrzeb.
- doskonała organizacja widoku - layout, widok akcji, proste partiale i komponenty, które są w zasadzie miniakcjami
- generacja modułu admina - świetna sprawa, gdyż moduł można łatwo modyfikować zarówno z poziomu konfiguracji jak i kodu gdy potrzeba nieco niestandardowych zachowań
- przykładowe zestawy danych, które można wgrywać do bazy danych po jej przeróbkach - nie trzeba po każdej zmianie dodawać testowych danych - robisz to raz a symfony będzie je potem wgrywać po zmianach
- ilość pluginów, które dodają najczęściej wykorzystywane funkcje. Potrzebujesz galerii - wgrywasz plugin i po sprawie
- ajax - ajax znam słabo, ale symfony robi to za mnie ;-)
- propel - czyli zapominamy o monotonii pisania prostych zapytań sql

I tak wymieniać można by bez końca. Cena, która się płaci za tą wygodę to zwolnienie aplikacji - ale przy dużych projektach nie jest to aż tak widoczne. Testy typu hello world bardzo zakłamują sytuację bo symfony nadrabia dość mocno do innych frameworków gdy aplikacja jest "sensownych rozmiarów. Pisałem już kiedyś na forum o tym.
Paradoksalnie dla przykładu moje projekty przepisane na symfony zwzwyczaj przyspieszają, gdyż mogę prosto zastosować cachowanie - wcześniej nie chciało mi się w to bawić, ale w symfony cachowanie jest tak proste i intuicyjne, że grzechem było by nie skorzystać ;-)

Szukam frameworka który będzie w miare prosty, najlepiej z polską dokumentacją i i w miare funkcjonalny (to mój pierwszy framework)

jaki polecacie ?

Zacytuje kilka postów wyżej mike'a

czytałem i nie znalazłem nic co by miało jakaś obszerna polska dokumantacje...

Ech, tak to chyba tylko w Erze... . Najbardziej zadziwia ten warunek z polska dokumentacja, jezeli angielski sprawia ci az taki problem to radzilbym zaczac nauke jak najszybciej. Do czytania dokumentacji nie wymagana jest jakas zawrotna wiedza.
Co do wyboru, ja mimo wszystko polecilbym Kohane, nie przytlacza ogromem, w miare prosty, niezle udokumentowany. Dobry na poczatek moim zdaniem.

pozdr

kohana i "nieźle udokumentowany" ładny oksymoron ta dokumentacja nie nadąża za zmianami, jeszcze nie uzupełnili jej do 2.2 a już jest nieaktualna

@normanos, tak się kontrolnie zapytam, czy wraz z tymi zmianami idą zmiany API, czy tylko nowe funkcjonalności bez BC?

Zmiany API też.
Rozgorzała dyskusja na forum Kohany, że troche za dynamicznie się rozwija itd. ale ostatecznie ustalono, że tak ma być, ze zmiany są dużo dające, idą w kierunku PHP6 itd. więc ludzie się pogodzili.
Maja zamrożony 2.2.1, a jak wypuszczą 2.3 za kilka miechów to od nowa nauczyć się trzeba będzie tych istotnych zmian.

Dla mnie aktualna dokumentacja, wraz z calkiem przystepnie opisanym kodem, w zupełności wystarczyła do poznania tego FW. Nie ma co się oszukiwać, Kohana to żaden kombajn w stylu Symfony, Cake czy Zenda.

Co do zmian w 2.3 to istotnie jest to duży problem, ale głównie ze względu na tempo w jakim te zmiany następują. Naprawde nie sposób przewidzieć czy z koleji w 2.4 Shadowhand'owi nie zwidzi się jakaś kolejna innowacja, mająca wpływ na cały poprzednio napisany kod. Moim zdaniem to uniemożliwia oparcie na Kohanie jakiekoś poważnego projektu.
My na szczęście w firmie postanowiliśmy dokonać dużych zmian już wcześniej, więc w pewien sposób zrobiliśmy fork fork'a i nie dotyczą nas zmiany w 2.3.

pozdr

polecam ZF może nie ma polskiego wsparcia ale jest świetny nie zamieniłbym go na nic innego. Stosowałem troszkę symfony ale nie przypadł mi do gustu.

Twoj framework to najlepszy framework

Frameworki to przezytek i nie rozumie czemu mialbym uczyc sie cudzego frameworka zamist napisac wlasnego jak robie system informatyczny to zaden framework sie nie sprawdzi a jak nie robie systemu to wykorzystuje jakis cms. W firmach it sie to stosuje bo jest dokumentacja ktorej nie czeba robic i przemial pracownikow maja. Jak ty bys z kolega zrobil frameworka to nie mogli by was zwolnic jakbyscie nie mieli do niego dokumentacji bo by mieli zonka. Powazne firmy stosuja wlasne rozwiazania to nie jest duzo pracy a masz to co dokladnie potrzebujesz.

Wystarczy klika prostych klas jeden intefejs i juz masz swojego frameworka z obsluga modulow, baz danych przy okazji wszystko bedziesz rozumial ,czegos sie nauczysz, nie bedzieszm mial problemow z rozwijam, nie bedziesz musial czekac na aktualna dokumentacje, nie bedziesz sie uczyl cudzych pomoslow tylko rozwijal i tworzyl wlasne

Frameworki to starata czasu i cofanie sie w rozwoju - szukasz rozwiazan, pomysl czego potrzebujesz, przejzyj net, ocen rozwiazania i stworz wlasne.
Ucz sie od najlepszych patrz co robia az sam sie staniesz najlepszy, a jak bedziesz tylko wykorzystywal ich rozwiazania i je rozwijal to bedziesz stal w miejscu. Pozatym stosowanie cudzych rozwiazan 99% nie sprawdza sie przy tworzeniu systemow informatycznych twoj klient w 99% nigdy nie poprosi o to samo o co ktos inny juz poprosil.

A najlepiej to qooxdoo http://demo.qooxdoo.org/current/demobrowser/ a po stronie php tylko i wylacznie polaczenie z baza danych, zapytania , system uprawnien i zabespieczen

Chory bełkot.

~emp a ten fragment najlepiej świadczy o tym, że nie masz najmniejszego pojęcia o czym piszesz:

Tia, a świstak siedział i zawijał w sreberka.

Naprawdę sadzisz, że tak trudno nauczyć się 3rd-party frameworka? I nie mówie tylko o obsłudze, ale całości. Korzystam od długiego czasu z Agavi i teraz znam ją prawie jakbym sam napisał.

@emp - ciekawa teoria ;-) Tylko jaką firmę stać na napisanie od podstaw frameworka, który będzie zbliżony funkcjonalnością do dajmy na to Symfony, potem przetestować to, napisać dobrą dokumentację i rozwijać. Zauważ, że nawet samo symfony nie tworzy wszystkiego od nowa, tylko używa sprawdzonych komponentów typu propel - po co to pisać od nowa? W Polskich realiach firm kilkuosobowych pisanie frameworka to nieporozumienie - to co ludzie z takich firm nazywają frameworkami to najczęściej zbiór kilku klas - ale to nie framework to komponenty... Na dodatek kompoenenty, które są zazwyczaj słabo przetestowane i zawierają więcej dziur niż ser szwajcarski. Dla porównania nad frameworkiem czuwa duża społeczność, która zgłasza błędy, moduły posiadają swoje test itd itp.
Tylko duże firmy mogą sobie pozwolić na napisanie tego typu frameworka na własne potrzeby.

Fragment o stosowaniu cudzych rozwiązań się nie sprawdza śmieszy mnie szczególnie. Framework to w tylko zbiór komponentów połączonych w pewną całość i narzucający pewien sposób wykonywanie czynności. Za pomocą jednego frameworka mogą napisać zarówno forum, stronę firmową, sklep czy portal społecznościowy - nie wiem czemu klient miałby mieć coś przeciwko stosowaniu frameworka, którego użyto do innego ;-)

Frameworki mają pewne wady, ale na pewno nie powodują "cofania się w rozwoju". Pisanie swoich rozwiązań w większości przypadków jest dla mnie śmieszne. Powiedz mi jak długo pisałbym coś takiego jak Propel czy Prototype? Jak długo pisałbym subframework do formularzy taki jak w Symfony 1.1? Jeśli natomiast dla Ciebie klasa będąca nakładką na mysqli, jakiś prosty router i klasa generująca panel typu CRUD to już framework to chyba rozumiemy pod tym pojęciem coś innego.

@emp: to teraz wpisz format C: i bierz się za pisanie nowego, swojego systemu, bo przecież korzystanie z cudzych jest cofaniem się. Ale nie... sorry, najpierw będziesz musiał napisać swój własny język programowania, bo przecież używanie C++ (czy innego) się nie sprawdzi w Twim systemie. Ale nie... przecież nie skorzystasz z klawiatury i PC bo... tak zgadłeś To cudze pomysły i rozwiązania - zaprojektuj wszystko od nowa. ...i tak dojdziemy do ~prehistorii.

A jeżeli ten przykład Ci nie pasuje:
po jaką cholere jakaś firma ma pisać swój framework? Przecież to jeden, dwa, trzy ... sześć miesięcy pracy całego zespołu programistów. A im trzeba zapłacić niemałe pieniądze, do tego wszystkie ZUSy, USy i inne ustrojstwa. A potem jeszcze Ci sami programisci będą mogli Cie szantażować


Zastanów się zanim coś napisesz.

To jest tylko moja opinia oparta na moim doswiadczeniu i pracy piszecie ze nie wiem o czym mowie okej nie przeszkadza mi to. Mam sporo doświadczenia, troche ukończonych projektów, niektóre bardzo zaawansowane i duze wiem o czym mowie nie zajmuje sie bzdurami tylko systemami informatycznymi czuje sie pewnie.

Moze z zewnatrz to tak wyglada ze uniwersalne rozwiazanie jest okej w kazdej firmie sie sprawdzi. Ja nie robie tylko oprogramowania moja firma je kupuje i to co chcial inny klient my tez chcemy ale to musi byc zmodyfikowane nikt nie chce dokladnie tego samego co ktos inny ten 1% roznicy to 99% roboty. Wiekszosc firm kupujaca oprogramowanie na zamowienie nie dostaje tego co chce bo uzywacie tego co juz macie zrobione, modyfikujecie co powoduje bledy, a jak sie nie da to sie mowi to jest niemozliwe taka jest filozofia systemu Robienie softu za 5tysiakow a za 500 to jest spora roznica ale tylko w cenie gheheh. Pogadal bym moze z wami na ten temat i tego co odpialiscie ale za bardzo sie podniecacie ja twierdze ze to wy nie macie pojecia za malo doswiadczenia i jeden punkt widzenia. Nie bede sie juz udzielal w tym temacie kazdy moze przeczytac wasza i moja opinie.

nie zrozumiałem... używanie rpzecinków i ponowne przeczytanie przed wysłaniem pomogłoby

z grubsza chodzi chyba o to ze kupujecie soft i go przerabiacie? to co to ma do frameworkow?

i że chyba kupują za 500,- a sprzedają za 5 000,-


Czy jakoś tak :]

Ja zdaje się zrozumiałem co chciał kolega powiedzieć, ale emp chyba nie rozróżnia frameworka od gotowego oprogramowania. Co za różnica czy oprogramowanie jest tworzone na podstawie frameworka czy pisane od podstaw? W sensie "dla klienta" oczywiście? Przecież używanie frameworka nei polega na przerabianiu tego samego softu dla 20 różnych klientów... Framework ma "tylko" automatyzować powtarzalne zadania.

Dobra już nie ma co karmić trolla. Koleś widać, że nie ma zielonego pojęcia co jest framework i jakie jest jego zastosowanie.
Choć z drugiej strony podziwiam determinację ludzi, którzy strugają swój własny młotek jak mają zamiar wbić gwoździa.

Żeby ta dyskusja wróciła do odpowiedniego, wyższego poziomu sugeruję pominąć wypowiedzi ~emp i nie odpisywać na nie. Część ludzi po prostu nie jest reformowalna.

@athlabus:
Fakt, stworzyć aplikację na pewno można szybciej przy pomocy Symfony (generator modeli, generator admina etc.). Problemy jednak zaczynają się w momencie gdy trzeba coś zmienić (np. dodać nowe pole do tabeli, które dodatkowo będzie w relacji z inną tabelą) lub zmienić wygląd admina. Wszystko jest oczywiście możliwe, tego nie neguję, jednak dla mnie było to bardzo upierdliwe. Może źle szukałem ale nie znalazłem w Internecie informacji w jaki sposób korzystać z widoków PostgreSQL. Nie podoba mi się również to, że pola w tabeli w bazie danych są uniwersalne tj. takie, które są poprawnie interpretowane w najpopularniejszych silnikach baz danych (ale to już nie wina Symfony tylko samego Propela). Pisząc system pod PostgreSQL chcę w pełni wykorzystyać listę typów danych, jakie oferuje ta baza. Co tam jeszcze... konfiguracja w *.yml. No dobra, fajnie, ale często miałem problem typu "!@#$% jak to zapisać w YML?". M.in. z tych właśnie powodów odszedłem od Symfony - za dużo kombinowania jak dla mnie.
Jeżeli dobrze Ci się kodowało w CI to zapewniam Cię, że w K będzie Ci się kodowało jeszcze przyjemniej. Wybór jednak należy do Ciebie, my możemy jedynie wyrazić nasze prywatne zdanie.

@phpion
Hehe tu właśnie dochodzi kwestia gustów. Każdy z nas ma inne oczekiwania do frameworka. Ja zrezygnowałem z CI z powodu kiepskiej obiektowości (wiem, że Kohana pod tym względme jest dużo lepsza) oraz ogólnie dużej prostoty (dużo rzeczy trzeba było sobie samemu dorobić). W Symfony cenię to, że 95% standardowych rzeczy mam "out of the box" i "ready to use". Wiąże się to też z pewnymi ograniczeniami - np. wspomniane przez Ciebie wykorzystanie Propela jako ORM. Widoki co prawda Propel wspiera, ale fakt faktem, że abstrakcja wymusza zrezygnowania z opcji niestandardowych, jak np. dodatkowe typu pól w Postgresie. Można oczywiście zrezygnować z Propela i pisać wszystko samemu, ale wtedy traci się wiele udogodnień, które oferuje w Symfony.
Symfony ma też ten "minus", że wymaga znajomości/douczenia się pewnych zagadnień typu Prototype, Propel, subframework do formularzy czy konstrukcja yml - wynika to z tego, że Symfony wykorzystuje wiele komponentów napisanych przez kogoś innego. Jest to z jednej strony plus (bardziej dojrzałe i przetestowane rozwiązania), ale z drugiej strony wymaga większego wkładu w naukę na początku aby móc wykorzystać 100% możliwości.

Ogólnie jednak powiem Ci, że testowałem 3 frameworki i w każdym dopisywałem sobie pewne "skróty" i dodatki. Po przerzuceniu się na Symfony okazało się, że tam już wszystkie te rzeczy były i to w zasadzie miały podobne api do tego co ja napisałem. Można więc powiedzieć, że w Symfony jest tok myślenia jaki ja preferuję. Teraz gdy powoli przerzucam się na Symfony 1.2 widzę, że dodano tam jeszcze więcej tego typu umilaczy. Ty masz pewnie podobnie w Kohanej.

No niestety, taka jest cena abstrakcji bazy danych. Ale przecież nie musisz korzystać z propela przy pisaniu projektu pod symfony - zawsze możesz korzystać bezpośrednio z sqli.

Jeżeli chodzi o możliwość wykorzystania dodatkowych typów z psql przy użyciu ORM, to *teoretycznie* mógłbyś tworzyć strukturę bazy za pomocą ręcznie pisanego DDLa zamiast generowanego przez ORM.

No coś Ty. W Kohana również mam abstrację bazy danych i nie mam żadnych wyżej opisanych problemów. Korzystanie bezpośrednio z raw SQL? W takim razie po co mi "dobrodziejstwa" Propela?


No tak, tylko znowu jesteśmy w punkcie opisanym powyżej: po co nam w takim wypadku cały Propel? W tym momencie staje się on przeszkodą niż ułatwieniem.

To jak to wygląda w Kohana? Możesz to pokrótce opisać, bo szczerze mówiąc nie znam tego, a jestem ciekaw. Chodzi mi o etap przygotowania schematu bazy danych oraz dostępu. I czy w Kohanie masz abstrakcję na obu tych etapach?

Nie, w K tworzysz bazę danych "ręcznie" (co dla mnie jest dużą zaletą), natomiast cała komunikacja z bazą danych realizowana jest z użyciem abstrakcji.

To w takim razie chyba się nie zrozumieliśmy - pisząc abstrakcja miałem na myśli również abstrakcję definiowania schematu bazy oraz budowania sqli. To dają rozwiązania typu propel i doctrine. Tego Ci nie da np PDO (chyba, że się mylę). Oczywiście nie mówię, że jest to zaleta - bo sam się męczyłem, jak za pomocą doctrina napisać trochę bardziej skomplikowane zapytanie i skończyło się na bezpośrednim wykorzystaniu PDO. Niestety, nie ma rozwiązań idealnych.

A czym Twoje rozwiązanie się różni od tego co napisałem wcześniej?

I chyba dalej się nie rozumiemy Kohana nie posiada generatora bazy danych na podstawie napisanego schematu (schema.yml). Cały schemat (tabele, kolumny, relacje itd.) tworzysz ręcznie. Natomiast jeśli chodzi o samą komunikację z bazą danych to K posiada warstwę abstrakcji bazy danych (MsSQL, MySQL, MySQLi, PostgreSQL). Dodatkowo (i chyba o to Ci chodzi) posiada tzw. query builder czyli narzędzie służące do dynamicznego tworzenia zapytań:
http://docs.kohanaphp.com/libraries/database/builder
Można również korzystać z bezpośrednich zapytań do bazy.

Ok, to rozumiem - piszesz ręcznie sqla z create table itp. Ale i tak tracisz przy tym abstrakcję, bo piszesz pod konkretną bazę danych. Za to możesz skorzystać z rzeczy typowych np tylko dla postgresa.



Czyli coś podobnego, co daje PDO. Czy ta abstrakcja w K korzysta z PDO czy to jest coś zupełnie innego?



Ok, czyli to jest jedyny element, którego nie masz w symfony jeśli decydujesz się na rezygnację z któregoś z ORM.

Jednym słowem - punkty 1 i 2 można osiągnąć w symfony, jeżeli zdecydowałbyś się nie używać propela (w sf 1.2 jest to nawet jako plugin, który można wyłączyć). Jedyne czego nie ma, to ten query builder.

Być może w kolejnych wersjach symfony pojawi się takie "lekkie" rozwiązanie wspomagające dostęp do bazy danych, lub ktoś wypuści jakiś plugin.

A propo kolejnych wersji - nie wiem, na ile ta strona zawiera prawdziwe oraz aktualne informacje
http://trac.symfony-project.org/wiki/Symfony2Discussion

ale jest tam coś takiego:
Orm:

• Propel 2.0
• ezPDO
• Doctrine
• "home made"
• Zend_db extension

nie korzysta. typowy ActiveRecord. ORM jako osobna biblioteka.

Ostatnio oglądałem sobie to całe Kochana Chyba nawet skuszę się na kilka "stronek" w tym, ale jak znajdę chwilkę czasu na przeczytanie dokumentacji, która pozostawia wiele do życzenia (wróć, jest po prostu dardzo słaba) i jak podłączę tam Propela 1.3.

jezu. jak @Mike zrobi cos w Kohanie to znaczy że świat stanął na głowie

ps. dokumentacja nie nadąża za zmianami ale taka fatalna to nie jest. chyba

Też jestem zdania, że nie jest najgorsza. Powiedziałbym wręcz inaczej: jest wystarczająca. Jeżeli mam jakieś wątpliwości to sobie przeglądam źródła klas i w bardzo krótkim czasie jestem w stanie połapać się co i jak działa (w przeciwieństwie do Symfony, a o Zend Framework już nie wspomnę hehehe).

// Edit:
Swoją drogą: dyskusja chyba zeszła nieco z tematu więc może lepiej byłoby przenieść niektóre posty do Wybór Frameworka?

j.w. cześć postów została wydzielona z Temat: [Symfony]Symfony_a_duze_projekty

można sobie w pare sekund wygenerować PHPDOCa ze źródeł Kohany, to też jest przydatne.

Wracając do tematu wyboru frameworka: ja mam dylemat nieco inny, zainstalowałem sobie ostatnio Symfony, które miało być frameworkiem pod mój nowy projekt i ... no nie powiem jego możliwości robią wrażenie, ale projekt nad którym pracuje będzie softem "pudełkowym", (czyli pobierasz i instalujesz na hostingu z PHP i MySQL), tymczasem z tego co do tej pory zobaczyłem - delikatnie mówiąc - Symfony średnio się do tego celu nadaje.

Po pierwsze przeglądając źródło w wygenerowanym pliku ProjectConfiguration.class.php mam linie:

[PHP] pobierz, plaintext 
<?php
require_once '/usr/share/php/symfony/autoload/sfCoreAutoload.class.php';
?>
[PHP] pobierz, plaintext 

czyli bezwzględny adres do pliku na moim localhost, nie wiem czy takich require'ów lub include'ów jest więcej, bo narazie mało co zrobiłem, ale utwierdza mnie to w moim przekonaniu

Po drugie w trac'u http://trac.symfony-project.org/wiki/SharedHostingNotSecure są specjalne patche i instrukcje jak instalować aplikacje na "shared hosting", to też mi dało do myślenia.

Na koniec, przeglądając strony zrobione przy użyciu Symfony (http://trac.symfony-project.org/wiki/ApplicationsDevelopedWithSymfony) zauważyłem że zdecydowana większość to serwisy (prawdopodobnie) na serwerach dedykowanych.

Na koniec dodam, że nie chodzi mi o to że Symfony jest złe a framework XXX jest lepszy, ale raczej o to, że Symfony nie zostało stworzone z myślą o aplikacjach które będą instalowane w setkach kopii (mam nadzieje ) na różnych hostingach, a na jednym serwerze dedykowanym i w przypadku takich aplikacji Symfony sprawdza się dobrze/świetnie/najlepiej (niepotrzebne skreślić)?

takie require jest 1 w konfiguracji, jak zrobisz freeze to biblioteki sf zostana przekopiowane do odpowiednich katalogów i nie ma sie co tym martwić

a co do kopii to owszem sf jest bardziej pomyślane pod serwisy pojedyncze na dedykowanych maszynach, aczkolwiek działają równie dobrze na dzielonych