Přejít k navigační liště

Zdroják » PHP » Symfony2, těší mě!

Symfony2, těší mě!

Články PHP

V tomto článku bych chtěl představit hlavní výhody a nevýhody PHP frameworku Symfony2. Osobně věřím, že Symfony2 se zanedlouho stane nejpoužívanějším PHP frameworkem na světě pro střední a větší aplikace a weby.

Nálepky:

Zend 1 je dnes již velmi zastaralý, Zend 2 je nevyspělý a nevidím u něj jasnou vizi. Framework Yii se stále drží ActiveRecordu a nevyužívá Dependency Injection. U Nette mi zase vadí pomalý vývoj, lokálnost, mizerná dokumentace a nepodpora některých moderních postupů (anotace, AOP, controllery jako services atd.).

Komunitu Symfony2 tvoří tisíce vývojářů. Framework se rychle rozvíjí, má obsáhlou dokumentaci a mnoho rozšiření (bundles). Jeho jednotlivé komponenty v poslední době začaly využívat nové verze známých open-source řešení jako Drupal 8 (článek), phpBB 4 (článek), Joomla (diskuse) a další.

Právě díky rozdělení frameworku na jednotlivé komponenty nemusíte Symfony2 využívat pouze jako celek. Některé firmy jako např. Medio Interactive využívají Nette v kombinaci s Symfony2 komponentami Console a Dependency Injection.

Symfony2 se používá ve všech zemích kolem nás. V Německu, Švýcarsku, velká poptávka po Symfony vývojářích je i v Anglii. Tohle se Nette zatím nepovedlo a dokud David nezačne pravidelně prezentovat v zahraničí, ani se povést nemůže. Pokud tedy budete chtít někdy pracovat mimo Česko, znalost Symfony2 vám pomůže najít uplatnění výrazně rychleji.

Dependency Injection i u controllerů, anotace

Symfony2 využívá Dependency Injection (DI). Služby se definují v YAML souboru místo Neonu v případě Nette. Ostatní je velice podobné (viz dokumentace). Symfony2 standardně nemá autowiring služeb, což lze ale jednoduše vyřešit instalací některého rozšíření (bundle). Např. můj jednodušší KutnyAutowiringBundle (inspirovaný DI v Nette), případně komplexnější JMSDIExtraBundle nebo AutowiringBundle.

Službou (service) mohou být v Symfony volitelně i controllery. Mám rád, když i u controlleru na první pohled vidím všechny jeho závislosti (v konstruktoru). Příliš mnoho závislostí (6+) mě nutí přemýšlet, jak kód controlleru zjednodušit/dekomponovat.

Užitečná je podpora anotací, např. pro definování routování a použité šablony:

/**
 * @Route(service="controller.hello_world_controller")
 */
class HelloWorldController
{
    /**
     * @Route("/hello-world", name="route.hello_world")
     * @Template("AcmeDemoBundle:HelloWorld:helloWorld.html.twig")
     */
    public function helloWorldAction()
    {
        return array(
            'greeting' => 'Hello world'
        );
    }

}

Anotace můžete v Symfony2 používat ve spoustě dalších případů jako validace formulářů nebo kešování. Mimo to si můžete díky rozšíření JMSAopBundle definovat i vlastní anotace, viz dále.

Aspektově orientované programování (AOP)

Pomocí anotací a AOP si lze často velice usnadnit práci a vyčistit kód. Uvedu příklad. Jak řešíte, když některé proměnné do šablony potřebujete sdílet napříč více controllery? Typicky jméno přihlášeného uživatele, stav jeho kreditu atd. Podědíte controllery? Co spíše controller „obalit“ jiným objektem, který do výstupu controlleru přidá požadované sdílené proměnné?

use Templating\Annotation\FillLayout;

class HelloWorldController extends Controller
{
    /**
     * @Route("/hello-world", name="route.hello_world")
     * @Template()
     * @FillLayout(service="layout_filler.front")
     */
    public function helloWorldAction()
    {
        $templateVariables = array(
            'greeting' => 'Hello world'
        );

        return $templateVariables;
    }
}

// Třída, která přidává do výstupu z controlleru "sdílené proměnné"
class FrontLayoutFiller implements ILayoutFiller {

    public function setDefaultVariables(array $templateVariables) {
        $templateVariables['currentUserName'] = 'Jiří Koutný';
        $templateVariables['currentUserCredits'] = 568;

        return $templateVariables;
    }
}

Díky uvedenému kódu budou proměnné currentUserNamecurrentUserCredits k dispozici v šablonách všech controllerů. Aby vše fungovalo, je potřeba:

  • Definovat u třídy import use Templating\Annotation\FillLayout,
  • U požadované metody použít anotaci @FillLayout(service=“[nazev sluzby]„)

Metoda setDefaultVariables() přejímá výstup z metody helloWorldAction() a „sdílené proměnné“ do výstupu přidá.

Pro lepší pochopení si projděte definici pointcutu, interceptoru a samotné anotace, wiring služeb a případně i dokumentaci k rozšíření JMSAopBundle.

Šablony Twig, Console

Symfony2 používá šablonovací systém Twig, který má podobné funkce jako Latte v Nette včetně dědění šablon, automatického escapování atd. Výhodou Twigu je především lepší podpora v IDE, viz dále. Jinak jsou oba systémy srovnatelné.

Zajímavou komponentou Symfony2 je Console. Umožňuje „ovládat“ Symfony2 aplikaci příkazy z příkazové řádky. Zapisují se následujícím způsobem: $ app/console [název příkazu] [argumenty] tedy např. $ app/console cache:warmup. Příklady nejpoužívanějších příkazů:

  • cache:clear – vymaže všechny keše,
  • doctrine:database:create – vytvoří databázi dle definic Doctrine2 entit,
  • doctrine:schema:validate – zkontroluje, jestli DB schéma odpovídá definicím Doctrine2 entit,
  • assetic:dump –watch – vytvoří různé předkešované javascripty, csska, obrázky atd. a v případě změny je automaticky aktualizuje.

Jako uživateli Windows se mi zpočátku „ovládání“ frameworku přes konzoli nelíbilo. Velice rychle jsem mu ale přišel na chuť. Některá vývojová prostředí (např. PHPStorm) umí příkazy konzole našeptávat, takže si příkazy nemusíte pamatovat.

Mimo systémové příkazy frameworku si můžete vytvářet i příkazy vlastní a automatizovat tak často opakované činnosti. Vytvořili jsme si např. příkazy pro:

  • service:add – přidání libovolné třídy do konfigurace DI containeru,
  • service:sort – abecední seřazení služeb v konfiguraci DI containeru (aby se lépe dělaly merge větví v GITu),
  • test:generate generování skeletonu phpUnit testu pro libovolnou třídu,
  • fixtures:apply – aplikování fixtures (vytvoří schéma databáze dle definice Doctrine2 entit, aplikuje fixtures + example data).

Díky příkazu fixtures:apply je jednoduché přepínat mezi různými větvemi GITu (které např. využívají zcela jinou strukturu databáze):

  1. git checkout [nazev větve]
  2. app/console fixtures:apply

Výborná integrace s Doctrine2

Doctrine2 tvoří jednu ze základních komponent Symfony. Ano, můžete používat Symfony bez Doctrine2. Ve spoustě případů si tím ale zkomplikujete život. Zprovoznění Doctrine je otázkou nastavení několika konfiguračních direktiv. Samozřejmostí je zařazení všech Doctrine2 příkazů do příkazové řádky Symfony (viz výše).

Doctrine entity můžete (ale nemusíte) použít v kombinaci se Symfony formuláři. Po odeslání formuláře máte tedy k dispozici rovnou naplněnou určenou entitu, kterou můžete persistovat.

Podpora v IDE a obrovská komunita

Symfony2 velmi dobře podporují populární vývojová prostředí jako NetBeans (info) nebo PHPStorm (pomocí pluginu). Funguje zvýrazňování syntaxe šablonovacího systému Twig, našeptávání standardních anotací Symfony i Doctrine, našeptávání v konfiguračních souborech a mnoho dalšího.

Framework vyvíjí desítky vývojářů v čele s Fabienem Potencierem. Za posledních 9 měsíců vyšly už 2 velké nové verze a v nejbližší době bude vypuštěna verze 2.3 s dlouhodobou podporou (LTS). Do Symfony přispělo do dnešního dne 796 vývojářů a dalších 527 vylepšovalo dokumentaci.

Každá nová funkce je na Symfony blogu dobře propagována a dokumentována. Kvalitní dokumentace je obecně velkou předností Symfony. Co není v dokumentaci, to při nejhorším rychle najdete na Stackoverflow. Kvalitní dokumentace, rychlost rozvoje frameworku, obrovská komunita a globálnost jsou hlavní důvody, proč pracuji v Symfony2 místo Nette.

Mimo základní komponenty Symfony2 existují další stovky rozšíření (bundles). Pokud potřebujete propojení s Facebookem, použijete FOSFacebookBundle, Bootstrap framework jednoduše přidáte pomocí BootstrapBundle, když potřebujete urychlit načítání obrázků na webu, zvolíte např. SpritesBundle. Všechna rozšíření nainstalujete během chvíle pomocí composeru.

Automatický deployment

Symfony je samozřejmě možné deployovat nahráním souborů na server přes (S)FTP. V tomto případě je ale nutné ručně provést několik operací, které mohou deployment dost protáhnout. Pro pokročilejší uživatele nabízí Symfony promakaný deployovací nástroj Capifony, který vychází z automatizačního nástroje Capistrano.

Capifony umožní celý deploy zcela automatizovat včetně dočasné deaktivace aplikace, stažení zdrojů z repozitáře, instalace všech potřebných závislostí přes composer, kompilace javascriptů Google Closure compilerem, zahřátí keše a mnoho dalšího. Samozřejmostí je možnost vrátit se k předchozí verzi, pokud nasazení nové verze selže.

Nic není dokonalé

Z předchozích odstavců by se vám mohlo zdát, že Symfony2 je dokonalé. Není tomu tak. Za 6 měsíců práce se Symfony 2 v týmu 3 – 4 vývojářů jsem narazil na následující problémy:

Debug komponenta v Symfony je mnohem méně praktická než Laděnka z Nette. Především obsahuje mnohem méně informací a je (samozřejmě subjektivně) méně přehledná. Nepodařilo se nám zjistit, jak ukládat/posílat emailem kompletní výjimky vzniklé na produkčním prostředí. Laděnku z Nette lze naštěstí do Symfony relativně jednoduše přidat.

Symfony codding standards využívají mezery místo tabulátorů. Složené závorky se v jednom případě píšou na stejný řádek (if -else), jindy na nový řádek (class, function atd.). Konfigurační direktivy se nepíší v camelCase, ale v podtrzitkove_notaci atd.

Uvedené nevidím jako zásadní problém a osobně bych se klidně přizpůsobil. Někteří programátoři se ale ohledně standardů dokážou hádat do krve :) Nejen proto jsme ve výsledku používali bez problémů trochu upravené konvence včetně tabulátorů pro odsazování.

Zmíním také, že Symfony je v dev prostředí subjektivně dost pomalé. Pomalost je pravděpodobně způsobena využíváním anotací, neustálým kompilováním DI containeru a především díky velmi komplexní práci s assets pomocí Asseticu (obrázky, css, javascripty). Různými úpravami nastavení se tento problém dal částečně vyřešit, ale i přesto je podle mě pomalost na dev prostředí hlavním trnem v oku Symfony2.

V produkčním prostředí je Symfony2 díky kešování rychlé, ale pouze za předpokladu, že hosting používá APC. To může být u sdílených hostingů problém.

S masivním kešováním na produkci je spojeno také složitější hotfixování případných problémů. Není možné např. pouze upravit anotaci v PHP souboru a znovu načíst stránku. Symfony na produkci spoustu PHP knihoven různě upravuje a kešuje pro jejich rychlejší interpretaci. Velmi často je proto nutné krom samotné úpravy kódu ještě vyčistit keše pomocí cache:clear.

Posledním větším trnem v oku Symfony jsou formuláře. Autor formulářové komponenty (Bernhard Schussek) se vyloženě vyžívá v konfiguracích pomocí složitých asociativních polí (příklad). Bez neustálého koukání do dokumentace tak téměř nikdy nevíte, jak konkrétní formulář/formulářový prvek správně nastavit. Mám pocit, že vždy když se Symfony formuláři pracuji, chovají se úplně jinak. Nic nefunguje na první pokus tak, jak čekáte.

Představil jsem vám ty nejzajímavější vlastnosti, kterými si mě Symfony2 získalo. Bohužel už nezbylo místo na představení Asseticu (lepší správa „assets“, tedy obrázků, css, javascriptů atd.), HTTP kešovováníSecurity komponenty a určitě mnoha dalších.

Ale já už přece jeden framework umím!

V článku v žádném případě nechci hanit Nette. Je to na české poměry výborný framework. Jeho cílovkou jsou ale podle mě spíše menší projekty už např. díky tomu, že nepreferuje objektově-relační mapování (ORM – např. Doctrine2). Místo toho využívá vlastní řešení Nette\Database, které se IMHO pro větší projekty s více vrstvami a více programátory nehodí.

Symfony se nebojí pojmenování „enterprise PHP framework“, protože na větší projekty a businessy primárně cílí. Každý projekt se může postupem času stát velkým, tak proč nezvolit Symfony2 hned na začátku? Jakmile se jej trochu naučíte, tak si dovolím prohlásit, že produktivita bude minimálně srovnatelná s Nette.

Zkuste si Symfony2, základ je podobný Nette. Když se vám nezalíbí jako celek, určitě použijte alespoň některé komponenty, stejně jako Filip,  Tomáš nebo kluci z Media.

Pokud chcete o Symfony2 vědět víc, rád udělám školení. Napište mi na koutny@collabim.com. Pokud v Symfony děláte, podělte se o zkušenosti v komentářích. Díky!

Komentáře

Subscribe
Upozornit na
guest
52 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
jirkakoutny

Přímý odkaz na stránku školení http://www.jirikoutny.cz/skoleni-symfony

Jaroslav Kubíček

Formuláře v Symfony jsou podobná hrůza jako v Zendu. Co mi je známo, Nette tohle stále dělá nejlíp a v základních úkolech postačuje, osobně tedy dávám přednost Nette a pro specifické úkoly Symfony komponenty (Console, Process), cboden/ratchet pro web sockety a pro javascript a css se mi zdaleka nejvíc zalíbily nástroje Bower & Grunt, zejména při vývoji, kdy mám minimálně 10+ less souborů a podobný počet js, jsou výhody zřejmé.
Model už je jen na mě, nic mi nebrání v použití Doctrine, Nette\Database by mohlo být z Nette klidně vyhozeno.

jkucharovic

Kritizovať formuláre v Symfony tým, že ich prirovnáš k formulárom v Zende a neukážeš konkrétny prípad onej „hrůzy“ – to je trochu zlý argument.

jirkakoutny

Se Zendem bych Symfony Form taky nesrovnaval. Udelat slozitejsi formular v Zendu pres ty ruzne silene dekoratory bylo peklo. V Symfony je to pohoda. Problem vidim spis v tech ruznych eventech, dispatcharech, transformatorech atd.

jkucharovic

Problém v Eventoch a veciach s nimi súvisiacich (Subscribe, Dispatch, Listener…), v DataTransformeroch je ako si v článku mnohokrát uviedol – subjektívny. Keďže Symfony je „enterprise PHP framework“ nie je tam žiadna „mágia“ – mnoho vecí je možné si podrobne nakonfigurovať. Pokiaľ Ti niektorý spôsob zápisu pripadá nepraktický, môžeš zaslať pull request :-)

Jaroslav Kubíček

stačí např. toto:

$formBuilder->add(‚dueDate‘, ‚date‘, array(
‚widget‘ => ‚single_text‘,
‚label‘ => ‚Due Date‘,
));

co mi na tom vadí:
– pole
– „magické“ stringy – lehčeji se překliknu, nemožnost našeptávání, nutnost neustále koukat do dokumentace co vše mohu, Nette cesta přes metody a konstanty mi přijde intuitivnější, ale nechci prosím tady vyvolávat flame.
IMHO Symfony není špatné, ostatně některé komponenty používám, ale pro mě jako programátora, který pracuje s Nette, prostě nemá žádnou killer feature, kvůli které bych switchul, to samé je asi i z druhé strany.

jkucharovic

Uznávam, že použitie stringov v konfigurácii nie je optimálne a použitie konštánt ako v prípade Nette je čistejšie a praktickejšie. Každopádne prirovnával si formuláre k Zendu, ktorý má formuláre navrhnuté zle od základu – viď napr. práca s validáciou á la InputFilterAware

jirkakoutny

Konfigurace přes asociativní pole jsou špatně přesně z důvodů, které jste popsal. To je bez debat.

Hlavní „Symfony killer feature“ je podle mě ekosystém všech těch rozšíření (bundles) a doplňkových nástrojů (Capifony) včetně lepší podpory v IDEčkách. Jasně, pokud máš připravený a vyladěný stack pro Nette, nemá smysl na Symfony přecházet. Určitě ne s českým projektem. Věřím ale, že za pár let tomu bude jinak.

jkucharovic

Debug komponenta (Web Debug Toolbar) obsahuje podstatne viac informácií ako „Nette\Tracy“, čo sa môže zdať subjektívne neprehľadné, ale v mnohých prípadoch to ušetrí veľa času.

Na logovanie výnimiek používa Symfony nástroj Monolog a v dokumentácii je podrobný návod ako ho nakonfigurovať aj na zasielanie výnimek e-mailom: http://symfony.com/doc/current/cookbook/logging/monolog_email.html

Vývojové prostredie mi na cca 4 roky starom notebooku s Ubuntu 13.04 x64 funguje pomerne svižne – v priemere spracuje stránku z cca 12 dotazmi na DB za 750ms a potrebuje na to 24MB RAM. Samozrejme, vždy záleží na zložitosti a efektivite aplikačnej logiky.

Aktualizácia cache v produkčnom režime sa dá pomerne jednoducho riešiť cez skripty v post-hook pri deploymente.

Formuláre sa na prvý pohľad konfigurujú možno zbytočne zložito, ale nie je to nič na čo by sa nedalo zvyknúť. Navyše, na formáre pre entity sa dajú jednoducho generovať cez konzolu: app/console doctrine:form:generate:form AcmeDemoBundle:NazovEntity

jirkakoutny

Jasne monolog umi ulozit vyjimku na produkci, ale AFAIK chybi cely stacktrace, gety, posty, promenne prostredi atd. Pro debug se mo hodi vice informaci.

Generovani formularu je samozrejme mozne, ale problem vetsinou nastane prave pri vytvareni slozitejsich formularu. Typicky kdyz potrebuju nektere elementy vyrendrovat za zaklade nejakych vstupnich dat z getu, postu atd.

jkucharovic

Priznám sa, že som nepotreboval tak „ukecaný“ error report. Ale u Monologu sa dá nastaviť vlasný procesor: http://symfony.com/doc/2.0/reference/dic_tags.html#dic-tags-monolog-processor , takže predpokladám, že by nemal byť problém nastaviť si zasielanie informácií, ktoré potrebuješ.

K problémom so zložitejšími formulármi viď môj komentár vyššie: http://www.zdrojak.cz/clanky/symfony2-tesi-me/?show=comments#comment-24547

jirkakoutny

My jsme na Laděnku byli dlouho zvyklí. Kolegy jsem dlouho přemlouval, ať dají Symfony Debugu šanci, ale asi po měsíci jsme skončili zpátky u Laděnky. Bylo pro nás holt jednodušší přidat Laděnku do Symfony, než si převykat. Jinde to samozřejmě může být jinak.

patie

Ja som naopak s formularmi v Symfony2 velmi spokojny, inak dobry clanok! Som rad, ze tento skvely framework podporuje aj niekto od nas.

David Grudl

Říkal jsem si, že nejlepší frameworky současnosti jsou Symfony a Nette a jsem moc rád, že článek tomu dává za pravdu. Třeba právě tím, že se nevyhne u popisu jakékoliv vlastnosti se srovnáním s Nette. A jak to tak čtu, ve většině aspektů stále vychází o něco hůř:

– počínaje absencí nejpodstatnější vlastnosti DIC – autowiringu
– zápisem konfigurace v méně expresivním formátu (Neon vs YAML)
– slabším šablonovacím systémem (nemá kontextově senzitivní autoescaping, návykové n:atributy atd…)
– horší ladící nástroje (a ty jsou pro vývoj zatraceně klíčové, kdo zkusil ví)
– horší formuláře (a to za pár dní přijde v Nette ještě revoluční pokrok)
– absenci jednoduché DB vrstvy (Doctrine „mají“ Symfony i Nette společně, ale lightweight alternativa v Symfony není)
– absence RobotLoaderu, což znamená složitější konfiguraci autoloadingu, nutnost dodržovat PSR0 nebo spoléhat na Composer
– absence komponentového systému v controllerech atd.

A jinak ano, komponenta Console je skutečně oblíbená a je skvělé, že jsi lze snadno použít i beze zbytku frameworku. Podobně se nyní rozděluji i Nette a debuggovací část bude (víceméně už je) dostupná samostatně pod názvem Tracy a ostatní budou následovat. Pevně věřím, že tohle pomůže Nette prorazit do světa.

jkucharovic

Zápis konfigurácie vo formáte Neon je naozaj silne subjektívna výhoda. Na formáte YAML ti niečo vadilo natoľko, že si spravil vlastný formát a ostatných osočíš, že nepoužívajú „menej expresívny formát“ – to príde mi trochu dogmatické.

Na základe čoho tvrdíš, že Symfony WDT je horší ladiaci nástroj než Nette\Tracy? Bez cynizmu – chcel by som vidieť prehľad s porovnaním toho, čo ktorý nástroj vie, na základe ktorého si to posudzoval.

David Grudl

Proč ten konfrontační tón? Jestli se cítíš osočen, tak se omlouvám ;-)

Syntaxe NEONu umožňuje zapsat název služby/třídy/továrny přímo s parametry (podobně jako v PHP), bez nutnosti to rozkládat do dvou řádků class a arguments. Lze toho využít i u jednotlivých argumentů a vyjádřit tak věci, které by se jinak řešily složitým opisem, např. http://goo.gl/Udj4H.

Pochopitelně konfiguraci je možné zapisovat i v YAMLu, každému dle chuti.

Že má Symfony horší ladící nástroj se píše v článku, přehled s porovnáním bych uvítal téže.

jirkakoutny

Ahoj Davide,

srovnání s Nette používám proto, že je na českém trhu defacto standardem. Ale jinak ano, Nette je dobré a možná patří i do první desítky nejzajímavějších PHP frameworků (zařadil bych možná ještě Flow3).

> A jak to tak čtu, ve většině aspektů stále vychází o něco hůř:

No ta „většina“ je dost subjektivní. Pro mě je to třeba úplně naopak.

> počínaje absencí nejpodstatnější vlastnosti DIC – autowiringu

Já upřímně také moc nerozumím, proč Autowiring není přímo v Symfony. Snahy jsou https://github.com/symfony/symfony/issues/836 ale většinou vyšumí protože „je na to bundle“. Ano, DI bez autowiringu je ohromný opruz a spousta Symfony komponent a bundle je kvůli tomu zprasených, protože autoři jsou líní psát wiring a proto raději injectují celý container.

Ve výsledku ale stačí nainstalovat bundle (1 minuta) a je to. Takže to nevidím jako nějakou zásadní nevýhodu.

> zápisem konfigurace v méně expresivním formátu (Neon vs YAML)

Davide, nevím. Předtím jsme v týmu asi rok používali Nette DI container (ne celé Nette) a Neon. Pak jsme přešli na Symfony a Neon. Kolegové pořád řešili jak je Yaml naprd. jak co nejdřív dodělají do Symfony podporu pro Neon a nakonec nic. Možná sem napíšou víc.

Ale ok, věřím, že Neon je lepší než Yaml. Dokážeš jeho podporu dostat do IDEček? V NetBeans už myslím je, co PHPStorm a další?

> slabším šablonovacím systémem (nemá kontextově senzitivní autoescaping, návykové n:atributy atd…)

Při přechodu na Symfony jsme kontextově senzitivní autoescaping pořád řešili jako věc, kterou Twig „přece musí taky mít“. Bez toho se přeci nedá žít. Nemá, ale my jsme AFAIK snad nikdy nepotřebovali. Další zmiňované vlastnosti jsou asi fajn, ale nepřipadají mi nijak zásadní.

Zásadní výhodou Twigu je fajn, že se dá použít samostatné. Což o Latte asi neplatí, jak mi někde v hospodě říkali kluci z Shopia, kteří právě z tohoto důvodu zvolili Twig místo Latte. Věřím, že ty komponenty oddělíš. Otázka ale je, kdy to bude a co v té době bude umět Twig navíc.

Ano, spousta komponent z Nette je super. Co se tedy maximálně soustředit na to, oddělit je a udělat jim v zahraničí pořádné promo? Není to lepší cesta, než promovat celý framework? Možná to už děláš, nevím.

> horší ladící nástroje (a ty jsou pro vývoj zatraceně klíčové, kdo zkusil ví)

Ano, ale „je na to bundle“ :) Původní Symfony Debug ale přeci jen hodně lidem stačí, jak naznačují další komentující. Symfony má zase úplně bombastický profiler. Nejlepší je tedy podle mě kombinace obou (Tracy + Symfony Profiler).

> horší formuláře (a to za pár dní přijde v Nette ještě revoluční pokrok)

Nette formuláře moc dobře neznám. Jen vím, že když jsme je používali, tak startovaly sessions (netuším proč). Mimo to nejsou moc DI friendy, POST data se do nich dostávala „nějak sama“. Jo a validaci chci mít definovanou také raději na entitě nebo jiném plain PHP objektu místo přímo na formuláři.

Nelíbí se mi ani Symfony Form ani Nette Form. Věřím ale, že Symfony formuláře mají k ideálním stavu blíž, i když to bude ještě dlouhý cesta.

> absenci jednoduché DB vrstvy (Doctrine „mají“ Symfony i Nette společně, ale lightweight alternativa v Symfony není)

Pro mě je Doctrine2 dostatečně „jednoduchá“ a nemám potřebu použít nic jiného. Jasně, není to pro každého. Symfony je ale vhodnější pro větší aplikace a pro ně je Doctrine2 IMHO nejlepší.

> absence RobotLoaderu, což znamená složitější konfiguraci autoloadingu, nutnost dodržovat PSR0 nebo spoléhat na Composer

Upřímně moc nevím, o čem mluvíš. Nikdy jsem s ničím takovým neměl problém. Ano, AFAIK spoléhám na Composer. Je v tom nějaký háček?

> absence komponentového systému v controllerech atd.

Komponenty v Nette neznám. Moji kolegové říkali, že není o co stát. Možná sem napíšou víc.

Ve výsledku jsi zmínil pro mě velmi málo podstatné věci. Mnohem podstatnější je dobrá dokumentace, obrovská komunita, super podpora v IDE, deployovací nástroje (Capifony), LTS verze, 100+ zaměstnanců SensioLabs ve 3 nebo 4 zemích, kteří se o Symfony starají, pravidelné články na Symfony blogu atd. atd.

Je to prostě local vs. global problém podobně jako Seznam vs. Google :)

David Grudl

Díky Jirko za obsáhlou odpověď. Rozhodně nechci polemizovat o jednotlivostech, mnohdy jsou věcí konkrétních potřeb a vkusu, a zastavil bych se jen u toho rozdělení Nette do samostatných komponent. Je to nesmírně složitý proces, ale má momentálně nejvyšší prioritu a po Tracy bude do konce prázdnin následovat Latte a potom další části frameworku.

Srovnání Seznam vs Google mě děsí, protože Nette narozdíl od Seznamu globální ambice rozhodně má :-)

Vojtěch Kohout

Že do toho vstoupím… Co se šancí na prosazení týče, ty podle mě klesají s každým týdnem. Tak dva roky nazpět mělo myslím Nette šanci o řád lepší. Teď se prostě nůžky minimálně mezi jím a Symfony 2 rychle rozevírají.

Píše se tu o řadě vychytávek, které Nette „má“ a Symfony 2 „nemá“. Jak zde zaznělo, jde o dost subjektivní záležitosti, ale co chci říct je, že kdyby v týmu kolem Symfony 2 ucítili potřebu té či oné vychytávky, jsem si jist, že by ji do pár měsíců měli také.

Zkrátka jde o rozdíl jeden hlavní vývojář s pár přispěvovateli versus desítky aktivních vývojářů.

Tohle píšu z pozice aktivního a spokojeného uživatele Nette. :/

bene

Jako spokojený vývojář v Nette bych se pod tímto podepsal.
Pokud bych chtěl být hodně kacířský, myslím si, že oddělené části Nette by díky světu Symfony mohly na rozdíl od celého frameworku získat globální reputaci.

jkucharovic

K argumentu voči absencii RobotLoaderu
V starších verziách používalo Symfony vlastný autoloader a jeho konfigurácia nebola zložitá: https://github.com/symfony/symfony-standard/blob/2.0/app/autoload.php

… nutnosť spoliehať sa na Composer
Autor Composeru Jordi Boggiano je jeden z hlavných prispievateľov do Symfony: https://github.com/symfony/symfony/contributors , takže na spoliehanie sa na Composer je logický krok.

David Grudl

Srovnej to s třířádkovou konfigurací RobotLoaderu https://github.com/nette/sandbox/blob/master/app/bootstrap.php#L17 a zejména s faktem, že u něj netřeba dál dodržovat jakékoliv konvence, tj. je možné používat libovolné knihovny s libovolnými konvencemi a všechno funguje na první dobrou.

honzamarek88

Tahle reakce mi přijde zbytečně moc ultimátní. Dá se proti ní argumentovat i bez vyzdvihování předností Symfony, které Nette vůbec nemá:

– počínaje absencí nejpodstatnější vlastnosti DIC – autowiringu

Ok. Chybí, ale dá se doplnit.

– zápisem konfigurace v méně expresivním formátu (Neon vs YAML)

yaml a neon vypadají jako vejce vejci – ale je fakt, že v yamlu se třeba Factory::create() jen tak zapsat nedá, nelíbí se mu ty dvojtečky. Spíš to ale vidím tak, že v symfony mají filozofii, že preferují textové labely v konfiguraci před nějakým DSL.

– slabším šablonovacím systémem (nemá kontextově senzitivní autoescaping, návykové n:atributy atd…)

Kontextově senzitivní autoescaping je hrozně přeceňovaná věc – v praxi to znamená jen to, že v javascriptu nemusím proměnné prohánět helperem json_encode. n:atributy mám rád, ale i twig má svoje silné stránky – v šablonách se nemotá ani kousek php, tečkový přístup k proměnným (a.b.c je třeba $a[‚b‘]->getC() ), přehlednější zápis argumentů helperů {{ neco|helper(1, 2, 3) }}, …

– horší ladící nástroje (a ty jsou pro vývoj zatraceně klíčové, kdo zkusil ví)

ten bluescreen má nette asi fakt lepší

– horší formuláře (a to za pár dní přijde v Nette ještě revoluční pokrok)

Jak v čem. V Nette mi citelně chybí třeba entity binding.

– absenci jednoduché DB vrstvy (Doctrine „mají“ Symfony i Nette společně, ale lightweight alternativa v Symfony není)

No a :) Kdo chce, ať si stáhne do Sf třeba Nette Database. Nette stejně nepřináší nějakou hlubší integraci NDB třeba s formulářema nebo tak něco.

– absence RobotLoaderu, což znamená složitější konfiguraci autoloadingu, nutnost dodržovat PSR0 nebo spoléhat na Composer

PSR0 mi nedělá problém, aspoň je v těch třídách (garantovaný) pořádek. RobotLoader také není použitelný pro načítání velké hromady tříd (např Doctrine + Symfony), protože mu to první načtení po smazání cache pak trvá dost dlouho.

– absence komponentového systému v controllerech atd.

Komponenty používám minimálně. Jednoduché komponenty se dají nahradim embdováním controllerů ze šablony. Pak navíc odpadá nutnost dědit si nějakou továrničku na komponentu z BasePresenteru.

maryo

Taky přispěju, Nette znám o dost míň, ale i tak oba frameworky jsou TOP z toho co jsem trochu poznal. I když i ostatní mají určitě světlý chvilky.

Autowiring v Symfony chybí, nedávno jsem se vyskytl u projektu, který používal bundle který používal bundle … který používal ten http://jmsyst.com/bundles/JMSDiExtraBundle/master/annotations

Ničí to API počuráváním a injectováním do soukromejch vlastností (respektive globální závislost na tom Bundlu). Asi by se našel jinej bundle kterej to dělá podle typu, možná se po nějakym podívám nebo napíšu, ušetří to psaní, ale IMO to není „nejpodstatnější vlastnost DIC“. Jinak má JMS ale pár lepších bundlů.

Neon je vychytanější, YAML je standard. Nicméně Fabienův parser spolkne pár věcí, který jsou ve standardu „reserved“ jako je třeba zavináč na začátku stringu neuvozenej uvozovkama a používá se to dost často. Pak už to vlastně neni YAML a menší výhoda postrádá smysl. PHPStorm to zkousne, NetBeans ne. Alespoň ne v tý době, co jsem ho používal. Ale ten kratší zápis mi nepřijde jako tak velká výhoda.

Twig parsuje výrazy. Tím pádem, krom těch pár níže napsanejch výhod, by to taky nikdy nemělo oznámit chybu s řádkem ze zkompilovanýho souboru. Tohle Latte neřeší, nebo má něco na způsob source mapy? Taky to má za následek možnost definice vlastních operátorů, pár nových jich tam je, ale bez toho se dá taky žít. Jinak mi je ale Smarty-like syntaxe Latte bližší, escapování podle kontextu je taky celkem fajn a n:atributy taky, ale zas tolik to nepostrádám.

Debug a Forms už taky bylo napsáno. Ale proč vlastně definovat v php něco jako „radio“, „checkbox“, „select“, „multiselect“? Proč ne jen „bool“, „string“ s možností výčtu, array apod. O tom, jak se to zobrazí, by měl rozhodovat nějakej skin nebo tak něco. Ale je fakt, že tyhle názvy jsou celkem zaběhlý. Ale Symfony k tomu má trochu nakročeno, např.

‚choice Field Type
A multi-purpose field used to allow the user to „choose“ one or more options. It can be rendered as a select tag, radio buttons, or checkboxes.‘

U některejch prvků jde možná jen o to jméno, ale to, jak se to vykreslí, by měl vědět jen nějakej skin v šabloně, se ten fomulář vykreslovat ani nemusí. V SF se ten skin alespoň v šabloně dělá, ale i tak to má mouchy. Třeba šablona toho základního skinu v SF neni nejčitelnější a něco z toho pak extendovat a upravovat neni úplně ono. Když chce člověk komplikovanější skin, tak sice se tomu snažim vyhýbat, ale je rychlejší místo zobrazení celýho formu najednou zobrazovat jednotlivý fieldy a naházet tam tu HTML omáčku „ručně“. I vývojáři zaměření na front-end by se v tom měli rychle zorientovat.

Doctrine je v PHP asi nejlepší ORM, ale k dokonalosti mu pořád IMO dost chybí. Dokud neni potřeba něco trochu nestandardního, nemusí se toho moc dělat ani přemejšlet, což je fajn, ale už jsem narazil na hodně případů, kde zdánlivě hodně jednoduchej problém v SQL se musel řešit složitě. Někdy je to požadavek, ale ta (zdánlivá) nezávislost na SQL dialektu v podobě DQL něco stojí. Upravovat https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php musí být radost.

RobotLoader může být fajn, ale PSR je taky fajn a když se čirou náhodou použije knihovna, která ho nepodporuje a nemá vlastní loader, tak je to většinou pár php souborů a ty stačí dopsat do classmapy composeru kterej už je samozřejmost.

Symfony Console je super, ale někdy se používá až moc, stejnej případ jako Anotace (který jsou tuším z Doctriny). Ta má dobrej systém anotací. Vytváření vlastních je tam velmi jednoduchý.

jirkakoutny

Díky za komentář. JMSDiExtraBundle je na můj vkus strašně složitý a magický. Zkus můj autowiring https://github.com/kutny/autowiring-bundle třeba se ti zalíbí.

maryo

Díky. Kód jsem nestudoval, ale vypadá to celkem slibně. Na nějakym projektu to vyzkouším.

Václav Novotný

Jirko, parádní článek!

Jsem rád, že ho konečně někdo napsal :) Doufám, že to neskončí pouze u jednoho článku. Symfony je skvělý framework a určitě nejsem sám, komu je líto, že se u nás zatím moc nepoužívá.

jirkakoutny

Díky, napíšeme společně seriál? ;)

Martin Hlaváč

Souhlasím s tím, že Symfony je skvělý framework a věřím, že ho používá více lidí než si myslíme. Blíží se nám i první setkání Brno PHP zaměřené právě na vydání první LTS verze Symfony 2.

Viz https://plus.google.com/117984759431441870162/posts/ggtCdmWsEac

Přidávám se k poděkování za článek, rozhodně bude dobré, když se Symfony 2 začne opravdu používat i v našich končinách :)

Martin Hassman

To je rozhodně výzva! 8-)

wandal

Symfony je vybornej fw, ale prijde mi, ze je k nemu dostupne velmi malo zdroju, jak se jej skutecne dobre naucit.Screencasty s vyvojem blogu uz asi nikoho nenadchnou. Kdyz pracuju se Symfony mam neustale pocit ze umim jen max 50% a nektere veci nedelam tak, jak by se meli, teda mi to aspon tak prijde. Zvlast pokud si prectu, co vsechno sf obsahuje. Chybi mi nejakej serial o Symfony, ktery nekonci u 10-teho dilu. Dokumentace neni spatna, ale studovat fw se podle toho IMHO neda.
Je zde sice zminovane skoleni, ale nemyslim si ze skoleni je v dnesni dobe resenim.

jirkakoutny

A v jakých oblastech máte pocit, že vám znalosti chybí nebo by mohly být lepší? Já osobně třeba moc dobře neovládám Security a kešování, což jsou rozsáhlé a pro větší projekty velice důležité součásti.

Co přednášky na Youtube http://www.youtube.com/user/SensioLabs ? Co případové studie? Co školení přímo od SensioLabs (ano, stojí asi €1500, ale věřím, že to stojí za to).

wandal

Mam pocit, ze neznam od vseho kousek. Me znalosti nejdou do hloubky. Velmi vazne jsem uvazoval o kurzu na knpuniversity.com, libi se mi moznost zvolit vlastni tempo studia, neni nic lepsiho nez videonavod, ale bohuzel uvadeny rozsah kurzu mne nepresvedcil. Ja bych uvital serial, pri kterem se vyviji nejaky klasicky system(eshop…). Pokud se vyuka bude zabyvat i zajimavymi tematy jako je prave cachovani, bezpecnost,, multijazycnost, komnikace s nejakym externim api atd atd pri cene do 2000 by to bylo fajn.

radek.zilka.3

Nějaký workshop by byl asi určitě fajn, hlavně kdyby se člověk mohl ptát na místě (případně dodatečně emailem). Zkoušel jsem různé frameworky Zend, SF2, Nette (to už je dlouho) a když jsem se prokousával těmi základními tutoriály, tak se občas objevili chyby, které jsem nemohl vyřešit a napadaly mě otázky (routing, překlady, modulárnost, rozhraní – admin/frontend) a dohledání odpovědí bylo nekonečné, tak jsem vždycky přestal. (Asi proto, že jsem to bohužel nikdy nepotřeboval).
Vždycky jsem si chtěl napsat CMS v nějakém frameworku, protože na těch stávajících mi něco nevyhovovalo, ale brzo jsem přestal, protože všechny moje požadavky zahrnovaly měsíce práce a než bych to vyřešil, tak už to bylo zase zastaralé :(

martin.bazik

ja som uz chcel parkrat so symfony2 zacat, ale odradilo ma niekolko veci:
app.php a app_dev.php, nutnost konfigurovat sluzby, routy pre kazde prostredie
routovanie a tvorba odkazov(nie je to take luxusne ako v nette)
formulare
je to objektivne pomale
chyba autowire
twig je hnusny, podobne ako sablony v railsoch
triedy maju kilometrove nazvy
vsetko je bundle, a stale treba nieco niekde registrovat

ale zase komponenty su super, bezne pouzivam console, event-dispatcher, process, a ine. monolog takisto. vsetky tieto komponenty maju integraciu aj do nette. takisto doctrine2 orm aj odm. dokonca existuje aj integracia symfony sessionov kvoli pouzitiu s ratchet. a bude aj aop extension…

cize nie je nic co symfony ma co by neslo pridat do nette.

a co sa tyka deployu, vo vyvoji je luxusny system na deploy akejkolvek php(mozno aj nephp) aplikacie, na sposob paas https://github.com/bazo/deployer

aj v nette sa daju robit enterprise aplikacie, bez najmensich problemov. vyhoda je, ze vsetko sa da prisposobit priapadne vymenit. zo symfony sa stava moloch ako je zend

jirkakoutny

Abych mohl reagovat, bylo by třeba, abyste jednotlivé věci víc rozepsal.

V čem je problém s app.php a app_dev.php? Nejsou moc sexy, ale vždyť se to jednoduše dá změnit a nastavit typ prostředí (dev/production) např. na úrovni virtualhostu, ne?

> nutnost konfigurovat sluzby, routy pre kazde prostredie

Nerozumím. Služby se musí konfigurovat i v Nette, ne? Routy explicitně zapsané v anotacích jsou naopak IMHO super.

> routovanie a tvorba odkazov(nie je to take luxusne ako v nette)

Nette tolik neznám, ale v Symfony mi tvorba odkazů přijde v pohodě. V čem je problém?

> je to objektivne pomale

Na produkci nikoliv.

> twig je hnusny, podobne ako sablony v railsoch

To je jen o zvyku :)

> triedy maju kilometrove nazvy

Které např.?

> vsetko je bundle

Všechno nemusí být Bundle. Otázka je, jak si to nastavíte. Každopádně bundles mi taky vždycky nevyhovují.

> a stale treba nieco niekde registrovat

Tak zase to není automagické. V jakých případech vám to připadá zbytečné?

Díky!

martin.bazik

> V čem je problém s app.php a app_dev.php? Nejsou moc sexy, ale vždyť se to jednoduše dá změnit a nastavit typ prostředí (dev/production) např. na úrovni virtualhostu, ne?

no ved prave to, ze to treba nastavovat. v .htaccess ktory nemoze byt verzovany

> Nerozumím. Služby se musí konfigurovat i v Nette, ne? Routy explicitně zapsané v anotacích jsou naopak IMHO super.

ano musia, ale staci raz, nie pre kazde prostredie. vid routy: routing.yml a routing_dev.yml – kedy potrebujete mat zvlast routy pre vyvoj a produkciu?

> Nette tolik neznám, ale v Symfony mi tvorba odkazů přijde v pohodě. V čem je problém?

s2: $this->generateUrl(‚_demo‘), routy musia byt pomenovane, z tohto vobec netusim kam smeruje, a to podrzitko
nette: $this->link(‚demo:‘), je to podobne ale mne notacia modul:controller:action vyhovuje viac, a nemusim lovit mena rout z configu
routy sa z controllerov musia ziskavat reflexiou -> dalsie spomalenie, je to rozlezene po suboroch,

> triedy maju kilometrove nazvy
napr: Symfony\Bundle\FrameworkBundle\DependencyInjection\FrameworkExtension
ale mozno to len mne pride moc ukecane

> a stale treba nieco niekde registrovat
> Tak zase to není automagické. V jakých případech vám to připadá zbytečné?
napr toto: to je este len sandbox a uz je tam 8bundles – samotna appka AcmeDemo je dalsi bundle, proste same bundle a registracie
v nette pridam modul, presentery a ficim, bez toho, ze by som niekde nieco nastavoval

mam poct, ze sf2 vychovava dalsiu generaciu lepicov kodu, lebo na vsetko je bundle, tak si nacpu milion budle do projektu, ktore robia milion veci, z ktorych sa pouzije jedna. napr https://github.com/FriendsOfSymfony/FOSUserBundle
https://github.com/symfony/symfony-standard/blob/master/app/AppKernel.php

Martin Hasoň

> prostředí a app.php x app_dev.php a routy
Pokud nepotřebujete více prostředí, tak je prostě nepoužívejte. Vytvořte si klidně místo app.dev soubor index.php. A to samé pro routy. Nechcete-li používat vývojářské nástroje (profiler), tak použijte pouze jeden soubor routing.yml. A pokud se používá routing_dev.yml, tak ten standardně vkládá přes odkaz routing.yml a obsahuje navíc jen speciální routy pro vývojáře. Takže určitě nemusíte routy zapisovat dvakrát.

Standardní distribuce Symfony to má takhle rozdělené, aby se nestalo, jak to bylo vidět na několika českých webech, že na produkční url adrese po stránce plave Nette lištička.

A poznámka k pojmenování rout. Routy si můžete pojmenovat jak chcete, dokonce i ve tvaru bundle_controller_action. A také si je můžete nechat automaticky generovat – samozřejmě přes bundle :)

martin.bazik

ja chcem pouzivat viacero prostredi, pri vyvoji chcem mat listicku alebo profiler, ale nechcem mat pre kazde prostredie samostatny front controller(app_*.php)

a zase sme pri bundle :)

Jan Machala

Nevim co myslis v tomhle kontextu front controller, asi jsi myslel „bootstrapovaci script“. Pri jednoduchym prozkoumani app.php zjistis, ze jake prostredi se nabootuje ovlivnis velmi jednoduse retezcem:

$kernel = new AppKernel(‚dev‘, $debug);
$kernel->boot();

My mame v praci jen jeden app.php a pritom mame vicero prostredi. Jake prostredi se ma zvolit ovlivnujeme na zaklade promenne prostredi, kterou konfigurujeme na urovni virtual hostu v nginx (obdobne to samozrejme jde i ve vh apache). To ma vyhody, ze se da specifikovat i pro selenia, phpunit a dalsi.

Pokud ti nevyhovuje explicitni specifikovani prostredi, muzes to udelat podobne jako defaultne v Nette na zaklade ip adress (aka magicky, ale inteligentne).

Nebo si zvolis uplne jinou strategii na vyber prostredi. Volba je na tobe.

jkucharovic

Pôvodne som nechcel reagovať na tie rádoby argumenty (už len používanie slov „luxusný“ a „hnusný“ v argumentácii znižuje jej váhu), ale keď začal Jirka Koutný, tak sa pridám:

> app.php a app_dev.php, nutnost konfigurovat sluzby, routy pre kazde prostredie
niečo konfigurovať musíš v každoum framworku

> no ved prave to, ze to treba nastavovat. v .htaccess ktory nemoze byt verzovany
nevidím dôvod prečo by sa nedal verzovať .htaccess

> ano musia, ale staci raz, nie pre kazde prostredie. vid routy: routing.yml a routing_dev.yml – kedy potrebujete mat zvlast routy pre vyvoj a produkciu?
nepotrebuješ – proste do konfiguračného súboru pre vývojové prostredie importuješ cez notáciu celý konfiguračný súbor pre produkciu:
_main:
resource: routing.yml

Má to výhodu, že vývojovú konfiguráiu nemusíš vôbec indexovať/verzovať.

> routovanie a tvorba odkazov(nie je to take luxusne ako v nette)
> twig je hnusny, podobne ako sablony v railsoch
k tomu som sa vyjadril v úvode – je to subjektívny pocit. Výhody Twigu pekne zhrhul Honza Marek – viď komentár vyššie

> s2: $this->generateUrl(‚_demo’), routy musia byt pomenovane, z tohto vobec netusim kam smeruje, a to podrzitko
nette: $this->link(‚demo:’), je to podobne ale mne notacia modul:controller:action vyhovuje viac, a nemusim lovit mena rout z configu
routy sa z controllerov musia ziskavat reflexiou -> dalsie spomalenie, je to rozlezene po suboroch,

Podtržítka tam byť vôbec nemusia. Pomenovanie je z mojej skúsenosti výhoda. Názvy si môžeš definovať ako chceš – napr. modul.controller.action.

Konfigurácia cez anotácie je iba možnosť – osobne som to nikdy nevyužil.

> je to objektivne pomale
Hlúposť – dodaj odkaz na výsledky relevatného benchmarku

> triedy maju kilometrove nazvy
Tie bežne používané nie.

> vsetko je bundle, a stale treba nieco niekde registrovat
V bežnom projekte stačí mať vytvorené 1 až 3 bundle. Pri vytváraní bundle môžeš použiť wizarda cez konzolu. Bundle môžeš spravovať cez Composer, takže odpadá „stále … registrovať“

jkucharovic

Ešte doplním k anotáciám – všetky anotácie (Route, ParamConverter, Template, Cache…) si Symfony spracuje a ukladá do cache, takže je jedno či si nakonfiguruješ niečo cez XML, PHP, YAML, alebo anotácie. Výsledok je vždy spracovaný a uložený do cache, takže to nie je žiadne spomalenie.

David Grudl

Můžu ještě k tomu pojmenování rout? Měl jsem za to, že jde o volitelnou věc (byť tedy netuším, k čemu by byla dobrá). Nebo v Symfony nelze udělat odkaz přímo na controller/action bez použití dalšího pomocného indentifikátoru?

Martin Hasoň

Pojmenování rout je povinné. Takže výchozí distribuce vyžaduje pojmenování rout.

Tento požadavek na routování vychází z jasného oddělení Symfony komponent. Routování má za úkol pouze práci s url (vygenerovat, zachytit). O žádných controllerech neví.

A v čem je to dobré? No třeba pro velké týmy. Tvůrce šablon přece nemusí znát konkrétní controllery a akce, které se navíc v průběhu mohou měnit. Ale tým se na začátku může shodnout na pojmenování rout.

Existují ovšem balíky, které vytváří routy automaticky na základě třídy (například pro REST architekturu) a není nutné je vůbec definovat – samozřejmě po dodržení určených jmenných konvencí.

Někteří zase preferují vytváření vlastních generátorů url nad komponentou Symfony Routing. Takže v šabloně se třeba použije {{ path_to_product_detail(product) }} a žádné nízkoúrovňové routy je nezajímají.

jkucharovic

Pri použití anotácií na konfiguráciu sú mená pre routy nepovinné – na routu odkazujem názvom balíčku (bundle), mena kontroleru a metódy, napr. acme_blog_post_view.

Považujem za praktickejšie odkázať na routu {{ path('hp') }} ako {{ path('acme_site_homepage_view') }}

martin.bazik

je to moj osobny nazor takze si myslim, ze luxusne a hnusne si mozem dovolit pouzit.

.htaccess nemoze byt verzovany lebo bud budem mat na locale produkcne prostredie alebo na produkcii vyvojove, ak mam dva vstupne subory, v htaccess mozem requesty smerovat len na jeden

co uviedol honza marek nie su nejake extra vyhody, ale su to fajn veci. kazdopadne so symfony sablonami je viac pisania

v beznom nette nepotrebujem ani 1 bundle, extension ani modul

jkucharovic

je to moj osobny nazor takze si myslim, ze luxusne a hnusne si mozem dovolit pouzit.

Používaj si slová aké chceš a aké ti tvoja slovná zásoba umožní. Písal som, že sa mi nechcelo reagovať pretože je to nepodložené vyjadrenie – nie argument.

.htaccess nemoze byt verzovany lebo bud budem mat na locale produkcne prostredie alebo na produkcii vyvojove, ak mam dva vstupne subory, v htaccess mozem requesty smerovat len na jeden

V tom prípade Ti doporučujem naštudovať si nejaké konfiguračné direktívy – napr. RewriteCond %{REMOTE_HOST} !^127\.0\.0\.1. Dosiahneš tým toho istého čo v Nette (ale predpokladám, že ti bude vadiť, že musíš napísať niečo navyše :-))

co uviedol honza marek nie su nejake extra vyhody, ale su to fajn veci. kazdopadne so symfony sablonami je viac pisania

Preňho a pre mnohých iný sú – pre teba nie; viď Davidov komentár. Je pravda, že niektoré zápisy v Latte sú praktickejšie.

v beznom nette nepotrebujem ani 1 bundle, extension ani modul

A? Nejaký kód tam hádam máš? Na jednoduchý web/aplikáciu v Symfony ti postačí jeden bundle – je to len slovíčkarenie.

martin.bazik

a este k tym sablonam
sf2:
{% block content %}
Hello {{ name }}!
Go to the login page
{% endblock %}

vs nette
{#content}
Hello {$name}!
Go to the login page
{/}

v nette trochu menej pisania a prehladnejsie, nemyslite?

martin.bazik

hups,
tak uvediem iba hrefy pri tych odkazoch
sf2:
href=“{{ path(‚_demo_login‘) }}“

nette:
n:href=“demo:login“

David Grudl

BTW, je děsně zajímavé sledovat fíčury jednotlivých frameworků i z toho pohledu, že co jedni považují za skvělé, druzí vidí jako smell.

Kdysi jsem představil podporu hashbang navigace v Nette a naštěstí mi včas došlo, že je to ultrablbost a nikdy se to oficiálně ven nedostalo. Ufff. Podobně se dívám třeba na ty routy zapsané v anotacích. To je dle mého wrong on so many levels, proto to třeba v Nette není (byť teda v jednom příkladu je ukázka něčeho podobného http://goo.gl/Xwa4Y).

Uvádím to jen jako zajímavost.

bene

Je zajímavé a docela přínosné sledovat tuto diskuzi. Jako několikaletý vývojář v Nette a lehce seznámený v Symfony bych rád přispěl do mlýnku postřehy a tak trochu i skrytými dotazy.

1. Předpokládám, že každý vývojář nebo tým má sestavený svůj sandbox z různých balíčků.
Nette se v několika případech prezentuje jako celistvé řešení, ke kterému je potřeba se dostat právě vhodným složením těchto balíčků. Pokud vezmeme v úvahu že každý preferuje něco jiného, existuje spousta balíčků řešící problém elegantně, jednoduše, lightwave, DI, lazy a k obrazu mému, pak Symfony vyhrává. Logicky, protože lze poskládat to samé co má Nette. Otázkou jak moc blízko popsané realitě se důležitá Bundle nacházejí.
Budu tedy počítat s předpokladem, že si každý poskládal svůj dokonalý base.

Za zmínku stojí že Nette, ačkoliv je zde prezentováno jako „super“ řešení v jednom, se bude rozdělovat. Ano, bude se rozdělovat na logicky větší části a ne jen Bundle který rozšiřuje jiný Bundle. Nicméně zmiňovaná Nette\Database je příkladná část na odloučení. Pak je ale její obhajoba bezpředmětná.

2. Routy – Pokud mohu registrovat nějaký RouteNameCreator, tak je vlastně jedno jestli píši n:href=“home“ nebo n:href=“:Front:Home:“. Naopak, možnost pojmenování některých rout se mi zdá praktické.

3. app a app_dev – Když se na ně dívám, tak se mi zdají jednoduché. U projektů v Nette jsem často viděl komplikovanější nastavování v index + bootstrap + configy pro prostředí + globální configy. Vypadá to jen jako jinak rozmístěné soubory než jsou v Nette.

4. Autowire = Nějaký Bundle (pokud existuje kvalitní, viz bod 1)

5. Šablony – Tohle bude asi hodně subjektivní. Twig jsem letmo zkoušel samostatně, ale nebyl jsem z něj nadšen. n atributy mají obrovskou výhodu, že stále píšete HTML kód „bez“ balastu kolem.

{{ if users }}
ul
{{ for user in users }}
li{{ user.name }}/li
{{ endfor }}
/ul
{{ endif }}

VS

ul n:if=”$users”
li n:foreach=”$users as $user”{$user->name}/li
/ul

Vypadá to ale, že má zajímavé featurky, jako třeba „a.b.c je třeba $a[‚b‘]->getC()“.
Podpora IDE je HODNĚ velká výhoda. Například Javascript je peklo, když do něj cpete Latte tak aby si zachovalo autoescape. Často pak děláme $(‚#user{!$user->id}‘) namísto $(‚#user‘ + {!$user->id}), protože zde nikdy nebude potřeba escapovat a IDE nám dál vesele napovídá. Navíc to vypadá lépe.

Kdyby latte vyšlo samostatně jako Nette 0.9, možná by mělo šanci být výchozím šablonovacím systémem v Symfony 2. Ha, hlavní přispěvovatel do Twig je Fabien :-D Každopádně zde má Latte šanci se předvést.

6. Nette\Database – Vzhledem k divokému vývoji a každým releasem „lot of fixes“ jsem vlastně ani nenašel odvahu jej použít. Už od verze 0.9 používám dibi a zůstal jsem u něj. Ligtwave database connecttor v Nette je pro mě, a věřím že pro značnou část vývojářů v Nette bezpředmětný.

7. Profiler jsem viděl zběžně. Vypadá dobře a vypadá to, že je tam informací dost. Nette panel je fine. Výpis chyb nemohu posoudit.

8. Dokumentaci Symfony jsem zatím neměl důvod procházet, ale pokud alespoň z poloviny dobrá, jak čtu, tak srdce vývojáře musí plesat. Zde má Nette co dohánět.

9. Formuláře – V Symfony jsem neviděl. Nette je má pěkně propojeny se šablonami. Dá se říct, že je radost je ručně vykreslovat, což nenastává zřídkakdy.
addBool(), addDate(), addInt() mi v Nette chybí už od počátku. Render na základě typu je jen logický krok. Ano dá se to v Nette vše dodělat, ale to jsme u Bundle. Viz Checkboxlist, který jsem použil v drtivé většině projektů a existují na něj tuším už tři addons.

10. RobotLoader VS PSR0 – RobotLoader načte i knihovny bez PSR0, ale ty kvalitní, které existují, mají jednoduché načtení includem jednoho souboru. Naproti tomu adresářová struktura dle namespace a názvu třídy je logická a přehledná. Někdy se hodí pravidla porušit, ale není to zase taková výhoda. Hledání konkrétních tříd pak stejně probíhá přes Ctrl+N :-)

11. Neon VS YAML – V Acme\DemoBundle je dokonce zápis služby v xml (otázka, jestli je to z důvodu složité konfigurace). Jelikož jsem byl zasvětcen do tajů autoloadingu (autowire next level) a mám již na to připravenou config extension, psaní services z velké části odpadne. Díky Juro ;-)

12. Rychlost na devel nemohu posoudit, ale při větším projektu je Nette taky zdechlé. Zvláš´t pokud připojíte assets a další. Tady už nezáleží tolik nasamotné Frameworku, ale na použití specifických rošířeních. Při mikro věcech to je fofr, ale to u Symfony předpokládám taky.

Nette má výhodu že je to celkem jednoduchý balík tříd s klasickou MVC, nad kterým postavíte webík raz dva a bude pěkně udělaný, udržovatelný, rozšiřitelný. Má docela dost util tříd, které řeší běžné problémy.
Dají se na něm samozřejmě dělat velké věci a pořád čistě a efektivně v týmu. Prostě tak jak by to mělo být.
Má naprosto špičkový šablonovací systém. Perfektní laděnka. Kvalitní DIC s možností konfigurace. Rozumnou tvorbu formulářů s příjemným propojením se šablonami. Profiluje se jako rychlý a bezpečný framework, což se mu dá rozhodně věřit. Cache, práce s obrázky, stánkování, User a spousta util tříd. Uchovává si čistotu kódu, řeší věci pragmaticky.
Bohužel by potřeboval dořešit dokumentaci, propagovat se ven. Také vývoj a vydávání nových verzí je občas velkou neznámou a někdy to konečné slovo jednoho člověka není úplně ideální. Taky byly dlouho nahlášeny bugy a přitom místo jejich vyřešení se vyvíjeli nové věci. Chápu, rozumím, nicméně to vrhá špatné světlo na Framework jako takový.

Symfony se zdá být velmi promakané s robustním návrhem a velkou základnou. Otázka je, jak moc si stovky Bundle drží úroveň samotného Symfony. Když jsem Symfony stáhl, docela mě polekal základní sandbox. Působí jako nabubřelý slepenec spousty věcí (což je ale záměrem a určitě né špatně).
Pokud je dokumentace Symfony a důležitých Bundle na takové úrovni, jak jsem z výše uvedených komentářů a článku pochopil, je to krása.
Asi Symfony obětuji nějaký víkend pro hlubší seznámení.

Zde jednoznačného vítěze ani poraženého nebude. Ale budu rád, pokud si Nette vezme ze Symfony to dobré

bene

13. Symfony\Bundle\FrameworkBundle\DependencyInjection\FrameworkExtension VS Nette\Application\UI\PresenterComponentReflection – Opravdu je to takový rozdíl? Ano Nette má většinu názvů kratších, ale v době kvalitních IDE co napovídají a doplňují to je naprosto zbytečná připomínka. Zvlášť když např. PHP Storm mi automaticky vkládá třídu při použití do use, takže v kódu mám jen new FrameworkExtension(), new PresenterComponentReflection() vše automatizovaně.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.