Wniosek jest jeden - do pisania aplikacji typu hello world nie warto używać frameworków. Pozatym IMHO taki benchmark niewiele mówi, bo przedstawia on sytuacje, w której framework jest wąskim gardłem. A w rzeczywistych sytuacjach dochodzą do tego jeszczcze czasy zapytań do bazy itp.

Zgadzam sie ze html i php wypada najlepiej w tym tescie ;p, ale dziwi mnie duza roznica miedzy FW.

W tym różnicach nie ma nic dziwnego. Po prostu różne frameworki są tworzone do różnych rzeczy. Przykładowo Symfony jest robione raczej pod projekt minimum średnie. Nigdy nie będzie dobrze wypadało w testach hello world. Nawet pobieżne zapoznanie się z Symfony pokaże Ci jak wiele rzeczy tam masz "out of the box" - autoloader klas, kompleksowa obsługa bazy danych, wygodna konfiguracja, kompleksowa obsługa i walidacja formularzy i tak można wymieniać bez końca. Niestety wczytanie tego wszystkiego "kosztuje" i w aplikacji typu hello world się nigdy nie zwróci.
W prostych frameworkach musisz z reguły robić takie rzeczy sam - także ich narzuty zwiększają się wraz ze wzrostem złożoności projektu szybciej niż np. w Symfony, ale w prostszych aplikacja są po prostu szybsze.

Prawda jest taka, że nie ma frameworka do wszystkiego. Przykładowo ostatnio pisałem system, którego zadaniem jest tworzenie stron na podstawie pliku tekstowego. Jeden system obsługuje wiele małych stron - coś jak proste blogi z tagami, kategoriami etc. Frontend takiego przykładowego bloga jest baaardzo prosty. Po prostu pobiera wpisy z bazy i je wyświetla. Backend natomiast to już trochę więcej pracy - musi sparsować plik txt i zrobić z tego bloga + modyfikacja wszystkich stron z jednego panelu, edycja artykułu "rich text" + zarządzanie kategoriami etc.

W końcu zdecydowałem się na stworzenie backendu w symfony a frontendu w kohana. Backend był zaawansowany i skomplikowany, musiał zarządzać dość wieloma formularzami, dużo operacji na bazie - stąd Symfony. Frontend miał być po prostu szybki i prosty - tu Kohana nadała się doskonale - jest lekka, 1h studiowania dokumentacji i już mogłem w niej napisać prostą aplikację - tworzenie frontendu w symfony mijało by się z celem bo nigdy nie chodził by tak wydajnie jak kohana - dodam, że frontendy muszą być instalowane wielokrotnie więc także rozmiar Kohanej (~1mb) miał tu znaczenie.

Z kolei pisałem też dedykowany sklep z portalem - tutaj NIGDY nie zdecydował bym się na Kohaną. Pisanie w Symfony dużych aplikacji jest o niebo wygodniejsze. Dla mnie Symfony jest prawie idealna jeśli chodzi o pisanie średniej wielkości aplikacji. Po prostu w Symfony po wstępnej konfiguracji robisz tylko to, co robić powinien programista, a nie na przykład walidujesz ręcznie ciągle te same formularze, głowisz się jak dodać filtry czy wymyślasz sposoby na cachowanie danych.

Mógłbyś podać jakieś konkretne argumenty? Ja osobiście jestem zwolennikiem Kohany i (nie wiem czy to do niej odnosisz) stwierdzenia:

są wg mnie totalnie chybione. Wszystkie wymienione przez Ciebie elementy w Kohanie są bajecznie proste (może aż zbyt proste i nie do końca "pro"). Walidacja formularzy (w tym tworzenie własnych walidatorów), filtry (zwykłe metody statyczne) czy cache'owanie danych to jest dosłownie chwila roboty. Niestety (przynajmniej dla mnie) w przypadku Symfony tak nie było. Może dla kogoś kto zna Symfony od podszewki nie jest to problem ale ja często miałem dylematy typu "jak działa ten walidator?".

Piszesz, że na Kohanej nigdy nie oparłbyś sklepu wraz z portalem - a ja właśnie tak zrobiłem. Coprawda jest to sam sklep internetowy, bez żadnego dodatkowego portalu, ale jednak ma sporo (głównie w adminie) funkcji. Przewidując przyszłość nie uśmiechałyby mi się (przykładowo) ciągłe przebudowy modelu w przypadku dodania/usunięcia jakiejś tam funkcjonalności. Pewnie masz w tej kwestii większe doświadczenie ale ja tylko raz miałem okazję pracować na Symfony w przypadku serwisu, który funkcjonował w sieci (dość spory i znany serwis) więc wszelkie zmiany, których musiałem dokonywać, sprawiały, że miałem pełne majty kału. Ponadto sprawa backendu: czy jesteś w stanie w 100% dostosować go do potrzeb klienta (stosując generatory)? Stworzyć takie formularze jakie są potrzebne (wiem, można używac partiali, komponentów), a nie takie jakie można stworzyć? Dla mnie właśnie takie ograniczenie stało się coraz bardziej wkurzające. Wolę mieć pełną kontrolę nad tym, co robię, a nie bazować na tym, co mogę zrobić.

Nie twierdzę, że Symfony jest do bani. Wręcz przeciwnie: jest to kawał genialnego kodu. Po prostu nie trafia idealnie w moje potrzeby przez co mam innego faworyta, którego będę bronił

A jaki to ma związek z symfony?
Nie sądziłem, że jest zakaz pisania backendu samemu Przecież generatory można wykorzystać w części lub tylko do utworzenia szablonu rozwiązania. Potem kodować możesz samemu równie skutecznie.
Uszanuj to, że inne rozwiązanie nie trafia w cudzy gust. To że Ci się podoba Kohna nie znaczy że musisz przekonywać tych, którzy nie chcą być przekonani.
To się tyczy zwolenników dowolnego narzędzia.

Wiem, że to nie meritum twojego posta, ale:
wiesz, że te generatory to są opcjonalne? I jeżeli nie chcesz/nie umiesz się nimi posługiwać - nie musisz.
Sam się kiedyś o nie rozbiłem i nie tykałem Symfony przez ponad rok.

orasss, mimo wszystko

Agavi rządzi!

edit:

do @phpiona to było

Ano taki, że w Symfony wiele rzeczy dzieje się automatycznie i nie zawsze ma się na wszystko wpływ.


A czy ja nie szanuję cudzych wyborów? No proszę Cię. Napisałem tylko swoje zdanie na dany temat. Poza tym: wychodząc z Twojego punktu widzenia to nie ma sensu wdawać się w jakiekolwiek rozmowy/wymiany argumentów. W takim razie po co ten wątek? Chyba właśnie po to aby poznać kilka zupełnie różnych opinii na temat różnych frameworków, prawda?


Tak, wiem. Również wiem, że wcale nie muszę używać Propela/Doctrine. Jeśli nie odpowiada mi mechanizm formularzy również mogę go olać. Ze wszystkiego zdaję sobie sprawę. Tyle tylko, że rezynując z tych elementów rezygnuje się równocześnie z tych elementów, które są główną siłą Symfony.

Phpion trochę źle mnie zrozumiałeś z moim postem - większa jego część nie odnosi się do Kohana. Uważam ten framework (chociaż znam go słabo) za bardzo przyjemny. Moim zdaniem jednak jest to framework idealnie nadający się do małych stron (co nie znaczy, że nie napiszesz w nim czegoś dużego, po prostu odbieram go w ten sposób). W Kohana pisze mi się dość przyjemnie.

Co do mojego stwierdzenia o tym, że w Kohanej bym nie pisałem większej aplikacji - np. dedykowanego sklepu opieram się przede wszystkim na tym, że w symfony zrobię to dużo szybciej, a jako że jestem bałaganiarzem to bardzo odpowiada mi to, że w Symfony jest taka poukładana struktura (niektórzy mówią, że sztywna).

Co do skomplikowania symfony to się trudno niezgodzić, że pierwszy projekt wymaga doczytania wielu rzeczy - nie jest tak jak w Kohanej, że dokumentacja jest tak mała, że można ją przyswoić w godzinę na tyle, aby czuć się komfortowo. Ale wynika to z tego faktu, że symfony ma być możliwie kompletnym frameworkiem, w którym user ma mieć możliwie dużo z pudełka.

Co do aktualizacji kodu etc, to nie wiem skąd ten kał ;-) Ja ciągle rozwijam projekty i dodaje funkcjonalności w sf i nie napotykam problemów - ot trzeba pamiętać, żeby wgrać pliki i wyczyścić cache... nic nadzwyczajnego.

Jeśli chodzi o wygodę generatora admina to:
- tak jak pisze mike nie ma obowiązku używania, to tylko jedno z narzędzi
- w 1.0 faktycznie był dość "cieżki" w przeróbkach, ale w obecnej wersji można już zrobić naprawdę prawie wszystko

Podobnie np. formularze - w symfon 1.2 to już jest osobne narzędzie, które wymaga chwili na poznanie (jest osobna książka do tego) ale w zamiana dostajesz najlepszą i najbardziej kompletną obsługę formularzy w php jaką kiedykolwiek widziałem.

Także reasumując jestem daleki od powiedzenia że Kohana jest gorsza od Symfony. Po prostu moim zdaniem jest to inna liga zastosowań. Nie pisałbym małych projektów w symfony bo to takie strzelanie z armaty do wróbla. Nie pisałbym dużych projektów w Kohana bo cenię swój czas i wiem, że w Symfony zrobię to znacznie lepiej i szybciej. Jeśli jednak Ty lubisz Kohana to nie widzę problemu w pisaniu w niej dużych projektów bo sam framework to tylko narzędzie i wszystko da się zrobić.

W pełni się zgadzam. Tak samo nie można powiedzieć, że VW Passat jest gorszy od VW Transportera

athabus:
"Co do aktualizacji kodu etc, to nie wiem skąd ten kał ;-)"

Myślę, że phpionowi chodziło o to, że jak chcemy dodać nową lub zmodyfikować istniejącą kolumnę w tabeli itp. w istniejącej już bazie danych z tabelami i danymi to trzeba dokonać migracji by nie tworzyć tabel na nowo i żeby dane nie zostały utracone i phpionowi chodziło pewnie o to, że to może się nie udać, coś złego może się wydarzyć podczas migracji itp., czy tak ?

?
Nie za bardzo rozumiem ten argument... Przecież gdy chcesz coś zmienić w bazie to ZAWSZE musisz:
- wprowadzić zmiany w tabeli
- wprowadzić zmiany w warstwie modelu

Nie wiem w czym tu Symfony ma być gorsze od innego frameworka. Przecież w każdym innym frameworku trzeba postąpić tak samo. Bo chyba nie chodzi Ci o to, że musisz ponownie wywołać propel:build-all? Bo przecież nie musisz (a nawet nie możesz) - wystarczy zbudować od nowa model, a bazę poprawić "ręcznie". Wiele razy już zmieniałem tabele, dodawałem nowe do istniejącego projektu etc. Nigdy nie jest to przyjemna operacja bo trzeba na chwilę zablokować aplikację, ale nie widzę żadnej różnicy między Symfony a "niesymfony".

A ja chyba wiem o co chodzi.
W Kohanie modele buduje się samemu, dzięki temu wiesz dokładnie co, gdzie i jak. W Propelu/Doctrine już nie do końca (polegasz na zewnętrznym kodzie w dodatku molochu) i jest stres, że coś nie tak będzie.
Fakt, jak znasz Propela/Doctrine od podszewki to to się wydaje śmieszne, ale ww czynnik występuje i chyba bywa powszechny

Ale po to wymyślono migracje... a te chyba są w Doctrine o ile pamiętam.

Dokładnie tak, o to mi chodziło. Pisząc model samemu orientuję się jak on wygląda i jakie są zależności. Natomiast w przypadku generowania kodu nie mam 100% pewności, że ingerując w dane miejsce nie naruszę innego. W Kohanie model można z powodzeniem zawrzeć w jednym pliku (nawet bez podziału na Klasa i KlasaPeer). Pracując w takiej sytuacji w jakiej ja pracowałem (brak pełnej lokalnej kopii, prace na funkcjonującym serwisie) wszelkie nanoszenie zmian łączyło się z niepewnością "czy wszystko jest ok".

Mam nadzieję, że to odpowiedni topic

Czy aby zacząć naukę któregokolwiek z Frameworków należy znać bardzo dobrze OOP ? Mam za sobą napisanie kilku całkiem rozbudowanych aplikacji, ale pisałem dotąd strukturalnie. W podstawach obiektowości się odnajduję, ale raczej nic więcej.
W planach miałem naukę ZF, ale czy wobec tego ma to sens, czy lepiej dokształcić się w OOP ?

Pozdrawiam

wydaje mi się że wystarczy jak same podstawy będziesz znał, reszty nauczysz się ucząc się frameworka...

radze się dokształcić albo wybrać prostszego frameworka takiego jak np. CodeIgniter czy Kohana. Zresztą zerknij na dokumentacje http://framework.zend.com/manual/en/ i sprawdź ile rozumiesz

Ostatnio dojrzałem do myśli aby zacząć używać frameworka. Chociaż nie do końca jestem zdecydowany ponieważ nie mogę znaleźć niczego pod moje potrzeby ale może źle szukam. Może ktoś mi coś doradzi.

- Przede wszystkim framework musi mieć czytelną i dobrą dokumentację. Po to mam go używać aby zaoszczędzić czas, a nie aby go nadkładać dla satysfakcji używania frameworka. Za kilka lat i tak będę używał czegoś innego.
- Podstawowe klasy takie jak wysyłanie emaili, obsługa obrazków itd. ale wykonane na prawdę profesjonalnie i solidnie. Za to bez zbędnych bajerów, których i tak nigdy nie użyję, a zaśmiecają całość. Jeżeli jest klasa do e-maili to obsługuje wszystko, łącznie z takimi opcjami jak hurtowe wysyłanie e-maili z załącznikami ale w taki sposób, że nie tworzy setek kopii jednego pliku dla każdego odbiorcy tylko rozwiązuje to optymalnie.
- Obsługa wyświetlania stron i komunikatów w wielu językach. itd. itp. Wszystkie podstawy używane przy tworzeniu stron. Natomiast bez zbędnych wodotrysków bo je i tak trzeba napisać samemu.

Mam nadzieję, że w miarę zrozumiale napisałem swoją ideę frameworka i znajdzie się coś takiego.

kohana chyba najlepiej pasuje zwłąszcza z ta dokumentacją na poczatek powinno Ci wystarczyć

standardowo mogę polecić Yii

A mi się wydaje, że Kabraxis szuka zbioru klas a nie frameworka ;-)
To co napisałeś to tak na prawdę w każdym frameworku dostaniesz, bo w każdym frameworku możesz używać klas zewnętrznych. Nie napisałeś natomiast nic o wymaganiach co do samego frameworka, do rodzaju aplikacji jakich chcesz w nim tworzyć, do sposobu wykorzystania bazy danych etc itd. Same klasy we frameworku to rzecz drugorzędna, bo nawet jeśli nie odpowiada Ci dana klasa np. do wysyłania maili w frameworku to po prostu używasz innej. Framework to nie to samo co zbiór klas.

Obawiam się, że athabus ma rację. Zawsze postrzegałem frameworki jako zbiory klas mające na celu ułatwiać życie. Pisząc poprzedniego posta tak na prawdę miałem w głowie zbiór klas, z których mogę korzystać. Wyszło na to, że chyba nie do końca rozumiem ideę frameworka heh.

Odpowiadając na pytanie co chcę w nim tworzyć.
Właściwie tylko i wyłącznie skrypty komercyjne takie jak:
- sklepy
- system magazynowy
- system fakturowania
- inne komercyjne takie jak np. serwis ogłoszeniowy, program partnerski itd.

Podsumowując wszystko dla zastosowań komercyjnych.

~Kabraxis
W zasadzie każdy framework by pasował do Twoich potrzeb (oczywiście mowa o aplikacjach).
Jeśli potrzebujesz zbioru klas, które potrafią zrobić wszystko, to polecam Zend Famework, który takim zbiorem właśnie jest. Oprócz tego, że posiada masę funkcjonalności, to można jeszcze go używać jak każdego innego frameworka opartego o MVC.

Wspomniałeś o tłumaczeniach a tutaj ZF nie ma konkurencji. Przetłumaczenie strony to kilka opcji (zobacz obsługiwane adaptery) i z automatu działa na choćby formularzach, możesz nawet prostą regułką URLe przetłumaczyć.

Kabraxis prawda jest taka, jak mówi Batman - tj. każdy framework nada się do tego typu zadań. Każdy będzie ci proponował to co lubi (ja też tak zrobie :-))

Ogólnie jeśli chodzi o dobre klasy, to polecam Zenda. Bardzo fajne narzędzia dla każdego programisty. Nie polecam jednak stosowania tego jako frameworka. Zend (o czym było już wiele w tym temacie pisane) - to jest bardziej narzędzie na którym możesz zbudować dostosowany pod swoje potrzeby framework - jeśli nie masz doświadczenia w pracy z frameworkami to się po prostu pogubisz. Sam zaczynałem od tego frameworka i potrzebowałem dużo czasu, żeby coś z tego wykrzesać a i tak z perspektywy patrząc to udało mi się osiągnąć spory śmietnik ;-). Podkreślę, że wina leżała po mojej stronie a nie po stronie frameworka - ot po prostu zabrakło wiedzy co i jak należy robić.

Na twoim miejscu zdecydowałbym się na Kohana lub Symfony. Kohana jest proste (czasami do bólu) i świetnie nadaje się do małych i średnich aplikacji - podstawy można opanować w 1 dzień. Dla niektórych (dla mnie akurat nie) jest też plusem fakt, że jest to bardzo luźny framework - na narzuca tylu ograniczeń co inne, większe rozwiązania.

Symfony to już jak to się ładnie określa rozwiązanie typu enterprise, wymaga sporo nakładu czasu na naukę i praktykę, ale daje dużo w zamian. W Symfony aplikację tworzysz wielokrotnie szybciej niż w gołym php i (w mojej opinii) 2-3 krotnie szybciej niż w Kohana.
Prawda jest jednak taka, że jakikolwiek framework nie wybierzesz na początku będziesz zadowolony.

Jeszcze raz podkreślę, że samych klas (np. Zenda) możesz używać w każdym frameworku. Framework bardziej ma wspierać takie rzeczy jak przepływ akcji, routing, separację warstw, tworzenie widoków, obsługiwanie/filtrowanie żądań, cachowanie etc - klasy to rzecz wtórna. W przypadku np. Symfony jest takie często powtarzane powiedzenie żeby "nie wynajdować koła od nowa" - autorzy czerpią z innych projektów czyniąc je częścią swojego frameworka - np. nie tworzą własnego ORM'a tylko używają Propela/Doctrine, nie tworzą własnych bibliotek Javascriptowych tylko używają uznanych projektów itd.

Co do wyboru samego frameworka, to przeczytaj cały wątek, odfiltruj flamewar i wybierz coś dla siebie.

Panowie, dziękuję za wyczerpujące odpowiedzi. Dokładnie o takie informacje mi chodziło.

Na początek wybierz CodeIgniter. Nauczysz się sporo. Przynajmniej podstaw MVC.
Ja używałem juz CakePHP i od niego zaczynałem. Narazie stawiam na CI.

Przecież te dwa frameworki to dinozaury. Czego potencjalnie można się z nich nauczyć?
Od dawna stawiałem na nowoczesne rozwiązania (Symfony, Agavi, Propel) i cieszę się, po przeglądnięciu źródeł Cake'a i CI, że tak się potoczyło.

Ja tylko dodam, ze jak przeglądałem Zend frameworka to w stosunku do Symfony, zend jest strasznie zacofany.

Ostatnio postanowiłem przepisać jeden ze swoich serwisów.
Dotąd nie korzystałem z żadnych gotowych frameworków. W PHP siedzę od czasu wersji 3.0 i nabywana wiedza była rozwijana stopniowo wraz z rozwojem języka.
Nie czuję jakiejś wielkiej potrzeby wykorzystywania frameworka do moich projektów, ale...
1. wiele firm w ofertach współpracy wymaga znajomości ZF lub Symfony
2. obecnie zaciąganie kogokolwiek do pracy to uczenie go swojego własnego standardu, wypracowanego przez lata (który nie jest zbyt zgodny z tym, do czego przyzwyczaili się studenci związani chociażby z ASP.NET), frameworki zaś są jako tako znane ludziom szukającym pracy na stanowisku programisty PHP

W związku z powyższymi faktami muszę podjąć decyzję czy odnowić serwis (dość spory portal, łącznie z forum i społecznościówką) według własnego stylu programowania, czy też postawić na, któryś z frameworków. Tutaj pytanie - który? Wybór tylko pomiędzy ZF i Symfony - jeśli uczyć się czegoś nowego, to tego co przyda się w życiu zawodowym.
Jak działa tandem ZF + ZendStudio + ionCube (jakoś nie podoba mi się licencja ZendGuard'a)?
Termin jaki sobie postanowiłem na odnowienie projektu (system artykułów, galeria zdjęć, komentarze, streaming video, zalążek forum dyskusyjnego, konto użytkownika) to 3 tygodnie. W późniejszym terminie i w ramach wolnego czasu dalszy rozwój serwisu.

Póki co liznąłem przez szybę ZF przy okazji testowania Studio i...
1. czeka mnie sporo nauki - o ile z OOP problemów nie mam, o tyle ZF wymusza swój własny styl pisania i struktury plików
2. Czy warto przy tak ograniczonym terminie zasiadać do ZF i ewentualnie okroić wstępną funkcjonalność, czy też lepiej napisać po staremu, a któryś z frameworków poznawać na spokojnie?
3. System template'ów - ten w ZF mnie przeraża - pliki CSS i HTML przygotowują w firmie graficy i szkolić ich z podstaw PHP... strach się bać - czy ciężko jest zastosować własny? Mam takowy, bardzo prosty - zbliżony do systemu stosowanego w phpBB2.
4. zapytania SQL... Trochę przeraża mnie wizja budowania prostych zapytań poprzez metody frameworka - czy to naprawdę jest aż tak efektywne? Jak dla przykładu zbudować wówczas takowe zapytanie:



Takie wyssane z palca, gdyż projekt nowej bazy nie jest jeszcze do końca przemyślany (ale będzie wiele relacji n...n).
5. Czy ewentualna migracja elementów wprost ze starego systemu jest w miarę bezbolesna, czy też nie obejdzie się od przepisania na nowo (wiele elementów pochodzi jeszcze z czasów przed OOP i php5)?

@kamilus - przez 3 tygodnie to się możesz frameworka nauczyć, ale raczej nie napiszesz w nim dobrej aplikacji. Jeśli masz taki limit czasowy to ewentualnie możesz użyć prostego frameworka typu Kohana. ZF/Symfony to dość skomplikowane frameworki - ich poznanie zajmuje sporo czasu i trzeba nauczyć się korzystać z nowych opcji.

Co do SQL to nie ma konieczności korzystania z wbudowanych rozwiązań typu Propel etc, ale jest to bardzo wygodne zwłaszcza przy prostych zapytaniach. Te bardziej skomplikowane/wymagające optymalizacji z reguły robi się ręcznie na poziomie SQL.

Ogólnie jeśli miałbym coś doradzać to sugerowałbym Symfony. Zend daje większą dowolność, co jest teoretycznie plusem, ale przez ten brak standardów w pierwszych projektach wychodzi wielki chaos. Symfony wymaga dość dużego przestawienia się na nowe rozwiązania, ale posiada w miarę zunifikowany system kodowania, więc łatwiej:
a) od razu pisać w miarę dobry kod
włączyć nową osobę do projektu

Zend jest bardzo fajny frameworkiem, ale dowolność sprawia że każdy koduje w nim inaczej. Jest to plus i minus. W Twoim przypadku, jeśli ma to być pierwszy framework to raczej będzie to minus, zwłaszcza ze masz ograniczenia czasowe.

Powiem jednak jeszcze raz, że jeśli termin 3 tygodni jest sztywny to raczej nie napiszesz tego dobrze w żadnym z tych frameworków bo różnica w stosunku do "ręcznego" pisania jest bardzo duża i trzeba poznać wiele nowych mechanizmów. Teoretycznie opanujesz je w kilka dni, ale zastosowanie praktyczne wymaga już trochę praktyki więc warto wypróbować to na jakąś mniejszą skalę.

Również bym optował za Symfony. Jak się zna symfony to prosty serwis/aplikację można zrobić w tydzień ale w 3 tygodnie nie nauczysz się żadnego frameworka nie mówiąc już o przepisaniu serwisu.

W Zendzie mamy:
- beznadziejną dokumentację, brak porządnego tutoriala przez co przez kilka dni mordowałem, pytałem i szukałem jak włączyć layout bo nigdzie nie napisali

- by zrobić 1 model trzeba wg ich mini tutoriala: http://framework.zend.com/docs/quickstart/...-database-table zrobić tak:

[PHP] pobierz, plaintext 
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initAutoload()
    {
        $autoloader = new Zend_Application_Module_Autoloader(array(
            'namespace' => 'Default',
            'basePath'  => dirname(__FILE__),
        ));
        return $autoloader;
    }
 
    protected function _initDoctype()
    {
        $this->bootstrap('view');
        $view = $this->getResource('view');
        $view->doctype('XHTML1_STRICT');
    }
}
 
//----------------------------------
 
; application/configs/application.ini
 
; Add these lines to the appropriate sections:
[production]
resources.db.adapter       = "PDO_SQLITE"
resources.db.params.dbname = APPLICATION_PATH "/../data/db/guestbook.db"
 
[testing : production]
resources.db.params.dbname = APPLICATION_PATH "/../data/db/guestbook-testing.db"
 
[development : production]
resources.db.params.dbname = APPLICATION_PATH "/../data/db/guestbook-dev.db"
 
//-----------------------------------
 
//stworzyc katalog
 
//-----------------------------------
 
<?php
// scripts/load.sqlite.php
 
/**
 * Script for creating and loading database
 */
 
// Initialize the application path and autoloading
defined('APPLICATION_PATH')
    || define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/../application'));
set_include_path(implode(PATH_SEPARATOR, array(
    APPLICATION_PATH . '/../library',
    get_include_path(),
)));
require_once 'Zend/Loader/Autoloader.php';
Zend_Loader_Autoloader::getInstance();
 
// Define some CLI options
$getopt = new Zend_Console_Getopt(array(
    'withdata|w' => 'Load database with sample data',
    'env|e-s'    => 'Application environment for which to create database (defaults to development)',
    'help|h'     => 'Help -- usage message',
));
try {
    $getopt->parse();
} catch (Zend_Console_Getopt_Exception $e) {
    // Bad options passed: report usage
    echo $e->getUsageMessage();
    return false;
}
 
// If help requested, report usage message
if ($getopt->getOption('h')) {
    echo $getopt->getUsageMessage();
    return true;
}
 
// Initialize values based on presence or absence of CLI options
$withData = $getopt->getOption('w');
$env      = $getopt->getOption('e');
defined('APPLICATION_ENV')
    || define('APPLICATION_ENV', (null === $env) ? 'development' : $env);
 
// Initialize Zend_Application
$application = new Zend_Application(
    APPLICATION_ENV,
    APPLICATION_PATH . '/configs/application.ini'
);
 
// Initialize and retrieve DB resource
$bootstrap = $application->getBootstrap();
$bootstrap->bootstrap('db');
$dbAdapter = $bootstrap->getResource('db');
 
// let the user know whats going on (we are actually creating a 
// database here)
if ('testing' != APPLICATION_ENV) {
    echo 'Writing Database Guestbook in (control-c to cancel): ' . PHP_EOL;
    for ($x = 5; $x > 0; $x--) {
        echo $x . "\r"; sleep(1);
    }
}
 
// Check to see if we have a database file already
$options = $bootstrap->getOption('resources');
$dbFile  = $options['db']['params']['dbname'];
if (file_exists($dbFile)) {
    unlink($dbFile);
}
 
// this block executes the actual statements that were loaded from 
// the schema file.
try {
    $schemaSql = file_get_contents(dirname(__FILE__) . '/schema.sqlite.sql');
    // use the connection directly to load sql in batches
    $dbAdapter->getConnection()->exec($schemaSql);
    chmod($dbFile, 0666);
 
    if ('testing' != APPLICATION_ENV) {
        echo PHP_EOL;
        echo 'Database Created';
        echo PHP_EOL;
    }
 
    if ($withData) {
        $dataSql = file_get_contents(dirname(__FILE__) . '/data.sqlite.sql');
        // use the connection directly to load sql in batches
        $dbAdapter->getConnection()->exec($dataSql);
        if ('testing' != APPLICATION_ENV) {
            echo 'Data Loaded.';
            echo PHP_EOL;
        }
    }
 
} catch (Exception $e) {
    echo 'AN ERROR HAS OCCURED:' . PHP_EOL;
    echo $e->getMessage() . PHP_EOL;
    return false;
}
 
// generally speaking, this script will be run from the command line
return true;
 
 
//--------------------------------------
 
//znowu stworzyc katalog
 
//------------------------------------
 
class Default_Model_GuestbookMapper
{
    protected $_dbTable;
 
    public function setDbTable($dbTable)
    {
        if (is_string($dbTable)) {
            $dbTable = new $dbTable();
        }
        if (!$dbTable instanceof Zend_Db_Table_Abstract) {
            throw new Exception('Invalid table data gateway provided');
        }
        $this->_dbTable = $dbTable;
        return $this;
    }
 
    public function getDbTable()
    {
        if (null === $this->_dbTable) {
            $this->setDbTable('Default_Model_DbTable_Guestbook');
        }
        return $this->_dbTable;
    }
 
    public function save(Default_Model_Guestbook $guestbook)
    {
        $data = array(
            'email'   => $guestbook->getEmail(),
            'comment' => $guestbook->getComment(),
            'created' => date('Y-m-d H:i:s'),
        );
 
        if (null === ($id = $guestbook->getId())) {
            unset($data['id']);
            $this->getDbTable()->insert($data);
        } else {
            $this->getDbTable()->update($data, array('id = ?' => $id));
        }
    }
 
    public function find($id, Default_Model_Guestbook $guestbook)
    {
        $result = $this->getDbTable()->find($id);
        if (0 == count($result)) {
            return;
        }
        $row = $result->current();
        $guestbook->setId($row->id)
                  ->setEmail($row->email)
                  ->setComment($row->comment)
                  ->setCreated($row->created);
    }
 
    public function fetchAll()
    {
        $resultSet = $this->getDbTable()->fetchAll();
        $entries   = array();
        foreach ($resultSet as $row) {
            $entry = new Default_Model_Guestbook();
            $entry->setId($row->id)
                  ->setEmail($row->email)
                  ->setComment($row->comment)
                  ->setCreated($row->created)
                  ->setMapper($this);
            $entries[] = $entry;
        }
        return $entries;
    }
}
 
//---------------------------------------
 
//itd. !! to nie koniec !! kodu jest znacznie wiecej !!
 
[PHP] pobierz, plaintext 

Tyle roboty dla jednego modelu Nie wiem jak Wy, ale ja i tak większości z tego nie rozumiem co tu się dzieje, w Symfony nie było tyle roboty.
A to nie jedyne wady ZF, ale z powodu tego jednego modelu już wyczerpałem limit znaków przeznaczony na jednego posta i więcej wad wymienić nie mogę

~wiewiorek bzdury wypisujesz.
Fakt. Dokumentacja nie należy do najlepszych. Jeśli szukasz czegoś więcej musisz mocno pogrzebać, by to znaleźć. Ale z tym layoutem to przesadziłeś. Przecież od tego masz Quick start (mini tutorial, jak to określiłeś).

A ten kod, który wkleiłeś to:
- index.php - punkt wejścia do aplikacji.
- bootstrap - klasa odpowiadająca za aplikację
- application.ini - plik konfiguracyjny
- skrypt pomocniczy, który stworzy bazę danych i uzupełni ją danymi
- właściwy model.
A ten tekst, że kodu jest znacznie więcej, to zapomniałeś o kontrolerze, widoku i dwóch pozostałych klasach modelu.

To co napisałeś to kod wymagany do stworzenia projektu, a nie samego modelu. To, że model został omówiony jako ostatni, nie oznacza, że musisz wykonać wszystkie kroki w celu jego napisania.

Pokaż mi frameworka, w którym działa model bez konfiguracji czy czegoś tak zbędnego jak index.php. Jedyne o co proszę, to rzeczowe argumenty.

Źle napisałem, miałem poprawić, ale zapomniałem - chodziło mi o uprawnienia - Zend_Acl, przez kilka dni szukałem co i w jakim pliku dodać żeby dostęp do danej strony miała osoba tylko o wysokich uprawnieniach, w symfony wystarczyłoby zrobić:

[PHP] pobierz, plaintext 
is_secure: on
  credentials: [wysokie]
[PHP] pobierz, plaintext 

i tyle, w końcu się poddałem i odpuściłem sobie Zenda. W Zendzie nieustannie trzeba dodawać kod, którego często nie rozumiem do plików: index.php, Bootstrap.php i application.ini - to mnie najbardziej wkurza. W Symfony nic takiego nie musiałem robić, a w Zendzie - non stop, przy każdej nowej funkcjonalnosci coś w nich trzeba dodać - to coś włączyć, to do czegoś ustawić ścieżkę itd. itp. - i żeby chociaż w jednym pliku albo żeby konkretnie napisali co i w którym pliku, a to nie, nic nie napiszą.


Przy użyciu konsoli w porównaniu do Symfony też wiele zrobić się nie da. Mogli chociaż zrobić, że jak chce skorzystać, np. z Zend_Acl to wydaję w konsoli polecenie i dodaje mi do tych 3. plików co tam trzeba, ale niestety takiego rozwiązania brak.

@wiewiorek:
Nie możesz negować ZF tylko dlatego, że nie dawałeś sobie z nim rady. Przez kilka dni szukałeś jak ugryźć ACL? No bez jaj - przecież w dokumentacji jest to ładnie napisane... Porównujesz ACL do ustawiania uprawnień w Symfony poprzez YML - pamiętaj tylko, że jest to pewien sposób zapisu konfiga. Dokładnie ten sam efekt mógłbyś uzyskać w ZF.

PS: dla jasności - nie używam ZF ani Symfony.

phpion w dokumentacji a i owszem jest opisane użycie Zend_Acl - UŻYCIE, nie ma natomiast co i do jakiego pliku dodać żeby Zend_Acl uaktywnić.

@wiewiorek - tak ZF ma słabą dokumentację... Brak słów. Dokumentacja ZF wg mnie jest bardzo dobra, znacznie lepsza i obszerniejsza niż symfony (jeśli już porównujesz). Chociaż, poprzez tą obszerność, niekiedy wyszukanie prostej informacji zajmuje sporo czasu.

Zend jako tako nie oferuje nam gotowych klas modelu, jednak oferuje klasy na których bazie możesz sobie model napisać. Możesz również wykorzystać jakiegoś ORMa (Propel, Doctrine) tak jak to jest w symfony.


To fajnie, że wkurzają cie rzeczy których nie rozumiesz. Pewnie chodzi ci o to, że aby dodać np. połączenie z bazą danych (czy jakiś inny "zasób" wg nazewnictwa zf) trzeba zainicjować w bootstrapie adapter bazy danych oraz ustawić dane do bazy w pliku konfiguracyjnym (co nie jest konieczne, bo możesz na sztywno w bootstrapie to trzymać ). No faktycznie, jest to nieziemsko skomplikowane i nielogiczne... Ciężko się w tym połapać, zwłaszcza że ZF ma tak marną dokumentację.

Ehh. Kiedyś oprócz umiejętności czytania, w cenie była umiejętność myślenia.

Jak już nie raz zostało to napisane, ZF jest zbiorem klas, z których możesz sobie napisać frameworka. Dokumentacja opisuje tylko poszczególne komponenty, a to jak je ze sobą połączysz, zależy tylko od Ciebie. Oczywiście są standardy tworzenia projektów w oparciu o ZF, ale nic nie stoi na przeszkodzie, by wyjąć np Zend_Form i użyć go z aplikacji niezależnej od ZF.

Jeśli wymagasz od frameworka dokładnych wytycznych co i jak masz napisać, a dokumentacja ma być zestawem gotowych przepisów na blog/forum/sklep/itd, to ZF nie jest dla Ciebie.

Z Zendem jest niestety ten problem, że reklamują go jako frameworka. Ktoś kto chce zacząć przygodę z frameworkami zazwyczaj wybierze właśnie Zenda bo w końcu tworzą go ludzie od php... i niestety w większości przypadków się rozczaruje.
Ja niestety zrobiłem kiedyś ten błąd. Aplikację jaką napisałem w oparciu można nazwać koszmarkiem ;-) - najlepsze jest to, że wtedy nawet nie wiedziałem, że to koszmarek i byłem z siebie bardzo dumny. Teraz gdy już mam pojęcia jak funkcjonują frameworki zrobiłbym to znacznie lepiej.

Co do dokumentacji to się nie wypowiadam, bo ja bawiłem się na etapie 0.7 więc trudno było oczekiwać dobrej dokumentacji - wtedy były opisane poszczególne klasy - nikt nie wspominał o tym jak używać ich jako całości. Jeśli jest tak nadal, to współczuję, bo nie jest to doby układ dla początkującego. Zdecydowanie dobre podejście do dokumentacji ma Symfony - tj. książka wchodząca w szczegóły każdego modułu + tutorial dla początkujących robiący taki przekrój przez wszystkie etapy tworzenia aplikacji. Dzięki temu osoba ma możliwość zapoznania się z istotą frameworka i później wie czego szukać w manualu.

Także rozumiem frustracje Wiewióra bo pare lat temu przeżywałem to samo - no może nie na taką skalę. Poruszałem się trochę jak dziecko we mgle. Dokumentacja techniczna bez "narracji" jak to wszystko połączyć jest bardzo denerwująca.

Trzeba zrozumieć podstawową rzecz - Zend to nie narzędzie dla osób nie znających frameworków. Zaczynając od tego frameworka można sobie wyrządzić dużo krzywdy nie zdając sobie nawet z tego sprawy, że robimy coś źle/nieoptymalnie. Nie zmienia to jednak faktu, że Zend to kawałem przyzwoitego kodu. Sam z niego korzystam, ale tylko jako biblioteki do Symfony.

Peter, ja robiłem plugina Zend_Acl,
w pliku bootstrap dawałem:

[PHP] pobierz, plaintext 
public function _initAclPlugin() 
    {
        $acl = new My_Acl();
 
        $fc->registerPlugin(new My_Plugin_Acl($acl));
    }
 
[PHP] pobierz, plaintext 

w applicatio.ini:

[PHP] pobierz, plaintext 
autoloadernamespaces.0 = "Zend_"
autoloadernamespaces.1 = "My_"
[PHP] pobierz, plaintext 

w index.php:

[PHP] pobierz, plaintext 
set_include_path(implode(PATH_SEPARATOR, array(
    realpath(APPLICATION_PATH . '/../library'),
    realpath(APPLICATION_PATH . '/plugins'),
    get_include_path(),
)));
[PHP] pobierz, plaintext 

i inne cuda i wciąż ten Zend_Acl mi nie działał.

No jak Wy lubicie zabawy z modułami i tyle kombinacji by włączyć coś tak podstawowego jak moduł odpowiedzialny za przywileje, zamiast korzystać z pełnowartościowych frameworków i skupić się na programowaniu to wasza sprawa. Dla mnie nowoczesnymi frameworkami są Symfony i pochodzący z innej bajki ASP.NET - można skupić się na programowaniu, wszystko inne można dodać albo z konsoli, albo z Visual Studio.

Albo kolejna wada - ten framework nie ułatwa podstawowych rzeczy. Przykład - logowanie - w Zendzie to byłoby coś w tym stylu:

[PHP] pobierz, plaintext 
$uzytkownicy = new Model_DbTable_Uzytkownicy();
        $form = new Form_Logowanie();
        $this->view->form = $form;
 
        if($this->getRequest()->isPost())
		{
            if($form->isValid($_POST))
			{
                $data = $form->getValues();
 
                $auth = Zend_Auth::getInstance();
                $authAdapter = new Zend_Auth_Adapter_DbTable($uzytkownicy->getAdapter(),'uzytkownicy', 'login', 'haslo');
 
                $authAdapter->setIdentity($data['login'])
                            ->setCredential($data['haslo']);
 
                $result = $auth->authenticate($authAdapter);
                if($result->isValid())
				{
					$storage = $auth->getStorage();
                    $storage->write($authAdapter->getResultRowObject());
					$storage->write($authAdapter->getResultRowObject(null, 'password'));
 
                    $this->_redirect('/');
                } 
				{
                    $this->view->errorMessage = "Błędny login lub hasło, proszę spróbować ponownie.";
                }         
            }
        }
[PHP] pobierz, plaintext 

Logowanie - podstawowa sprawa, które powinna wymagać ode mnie minimum kodu.
A tymczasem gdzie jest w tym odwalenie za mnie roboty ? Przecież ja sam musiałem ten kod napisać, a framework ma podobno przyspieszać pracę ? A dodatkowo do tego formularz logowania też trzeba samemu stworzyć - to ma być przyspieszenie pracy ? Przecież gdybym nie skorzystał z Zend Frameworka miałbym niewiele więcej pracy - musiałbym zrobić to samo co w Zendzie + napisanie prostej klasy.

Oczywiście w przypadku innych rzeczy takie podejście jak w Zendzie byłoby ok, ale tu przecież mowa o czymś tak podstawowym jak logowanie - to powinno wymagać minimum pisania kodu, a tymczasem tak nie jest.

Koniec z dyskusji z mojej strony, chcecie to zostańcie przy Zendzie, ja jednak wolę używać rzeczy, które przyspieszają tworzenie stron.

Nie jestem żadnym zwolennikiem ZF, osobiście wolę pisać w symfony, ale znam w pewnym stopniu obydwa frameworki.

A powiedz mi czy symfony samo z siebie automatyzuje autoryzację? Nie, trzeba samemu napisać formularz, samemu napisać odpowiedni walidator. No chyba że są jakieś nieoficjalne pluginy do tego, ale takie coś i do ZF by się znalazło. ZF oferuje nam za to narzędzie do autoryzacji, które możemy wykorzystać do autoryzacji http, czy zwykłego logowania na sesji.

Jeśli chodzi o te śmieszny przykład z Acl którego nie rozumiesz (tak pisałeś w poprzednich postach), to cie oświecę:



Ustawienie include path, aby można było w łatwy sposób includować pliki. Nie ma bezpośredniego związku z Acl. To się ustawia w każdym projekcie.

Daje nam to tyle, że aby coś includować (np. '../library/Zend/JakaśKlasa.php') to możemy pominąć część relatywną ścieżki ('../library'), a używać tylko 'Zend/JakaśKlasa.php'.


Ustawienie przestrzeni nazw dla autoloadera. Nie ma to bezpośredniego związku z Acl. To też się ustawia w każdym projekcie, ja osobiście mam to ustawione w bootstrapie, a nie w plikach konfiguracyjnych.


Tylko to odpowiada za rejestrację pluginu. Zaraz zaczniesz narzekać, że aby użyć Acl to trzeba utworzyć plik index.php i odpalić w nim bootstrapa...

Zdecydowanie na sam początek, do nauki najlepsze jest CI, prostota, świetna dokumentacja i łatwość użytkowania.

Nie wiem jak Wy, ale ja osobiście zalety CI cenię bardziej niż wsparcie dla php5, choć miło by było z estrony developerów jakby sobie o nim przypomnieli.
Niby jeszcze jest Kohana, takie niby ulepszone CI, ale wiele rzeczy jest tam zrobiona zupełnie inaczej i jak dla mnie jest troszkę irytująca, szczególnie to że nawet nie było przykładowych plików konfiguracyjnych, tylko trzeba było w necie szukać, no i to że nie mam takiej swobody jak w CI

jakich plików konfiguracyjnych? W katalogu system/config masz wszystkie wyjściowe wersje plików konfiguracyjnych. Wyjściowe, bo Kohana wspiera kaskadowość plików. Nie rozumiem również w jaki sposób Kohana ogranicza Twoją swobodę. Jak dla mnie K jest duży krok przed CI i jak na chwilę obecną nie zanosi się by CI ją przegoniło.

Takie dyskusje sa prowadzone przez ludzi, ktorzy nie maja pojecia o biznesie webowym.
Wiewiorkowi powinni zabronic tu pisac, jak mozna negowac framework, tylko dlatego bo nie potrafi sie go zrozumiec. A moze lepiej bylo zostac krawcem? (bez ujmowania krawcowm)

Moje główne zastrzeżenie dotyczy frameworków PHP w ogólności, konkretniej - implementacji MVC, która żadnym MVC nie jest. Weźmy pseudokod w stylu pierwszego lepszego frameworka:

[PHP] pobierz, plaintext 
public function costamAction()
{
 
   $model = Item_Model::create();
   $pagination = new Pagination($model->count(), 30);
   $data = $model->select('a, b, c)->where('foo = ?', $bar)->order('joe')->limit($pagination);
 
   $view = $this->getView('index');
   $view->data = $data;
   $view->pagination = $data;
   $this->contentManager->addView($view);
} // end costamAction();
[PHP] pobierz, plaintext 

Teraz pseudokod no-framework:

[PHP] pobierz, plaintext 
function costamAction()
{
   $pdo = Registry::get('pdo');
   $pagination = new Pagination(Count_Data('item'), 30);
   $stmt = $pdo->query('SELECT a, b, c FROM item WHERE foo=:bar ORDER BY joe '.$pagination->getLimit());
   $stmt->bindValue(':bar', $bar);
   $stmt->execute();
   $data = array();
   while($row = $stmt->fetch(PDO::FETCH_ASSOC))
   {
      $data[] = $row;
   }
   $stmt->closeCursor();
 
   $template = new Template('index');
   $template->data = $data;
   $template->pagination = $pagination;
   $template->display();
} // end costamAction();
[PHP] pobierz, plaintext 

I teraz pytanie stulecia: co takiego jest w pierwszym kodzie, czego nie ma w drugim, że pierwszy nazywamy "zgodnym z MVC", a drugi nie? Bo według mnie nie ma nic, a oba kody poza stopniem wykorzystania obiektówki, elegancją i poziomem opakowania powtarzalnych operacji nie różnią się zasadniczo od kodu, który potrafi napisać przy użyciu mysql_query() i funkcji pierwszy lepszy człowiek po dwóch miesiącach nauki PHP. Do tego dochodzi jeszcze mnóstwo kwiatków związanych z umieszczaniem danego elementu nie tam, gdzie powinien być (np. stronicowanie w kontrolerze).

Jak ktoś się uprze, to doprowadzi kod do postaci, gdy będzie to zgodne z MVC, tylko dlaczego w takim razie nie dostajemy takiej postaci od razu, skoro niby "MVC jest zaimplementowane"?

@Zyx, przyjrzyj się Agavi

Ok. A co jeśli jeden użytkownik na wysokim poziomie ma mieć dostęp do swoich stron i do stron ludzi o najniższym poziomie, a inny nie? A jeśli tylko fragermnt danej srony w zależności o d uprawnień ma być wyświetlany?
A jeśli ACL ma zależeć nie od "poziomu" że im wyżej tym więcej może ,a według przydzielonych uprawnień do konkretnych akcji/pól dla konkretnego urzytkownika/grupy?


To robisz sobie moduł logowania z konrolerem, helperem i modelem. I wklejasz jak to takie powtarzalne.
Oczywiście da się zrobić frameworka w którym piszesz:
[logowanie]
I już Ci obsługuje bazę danych, tworzy przekerowania, kontroler, wyświetlanie informacji... coś takiego już zrobiono, nazywa się Joomla. Jak chcesz programowąć to potrzebujesz dostępu do tych małych klocków. Jak masz tylko jeden klocek to jak przychodzi konieczność zmian/zrobienia czegoś nieszablonowego to leżysz i kwiczysz. Tutaj jest takie podejście że ja sobie składam z małych klocków większy kawałek strony, z którego korzystam wielokrotnie, a jak chcę zrobić coś niestandardowego to mam opanowane podstawy i wiem jak co poprzekładać.

Nie srpowadzajmy frameworków do łatwości CMSów typu Joomla, bo to inna działka. PRzecież nie chodzi o to żeby było tak proste żeby nie-programista programował używając frameworka. i jakiegoś tutoriala na 3 strony.

Ustawienia w security.yml w Symfony nie służą do określania tego co ma się wyświetlić tylko do określenia czy dany użytkownik w ogóle może wywołać daną akcję. Uprawnienia w yamlu można łączyć operatorami logicznymi i sprawdzać dowolną konfigurację uprawnień ale jeszcze raz zaznaczę że tylko w celu określenia czy daną akcję odpalić. W akcji wystarczy sprawdzić uprawnienia użytkownika wywołując

[PHP] pobierz, plaintext 
$this->getUser()->hasCredential('uprawnienie') 
[PHP] pobierz, plaintext 

i zrobić to co dla danego użytkownika ma się wykonać. Symfony ma naprawdę łatwy i przyjemny system uprawnień tylko trzeba go stosować z głową.

@Zyx - A gdzie wg Ciebie według Ciebie to powinno być umieszczone ?

Używał może ktoś ORM Designera dla Symfony i Doctrine/Propel ?
http://www.orm-designer.com/web/screenshots
Pobrałem i zainstalowałem wersję testową, fajna sprawa