Komentáře k článku
Symfony2, těší mě!

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.
Školení
Přímý odkaz na stránku školení http://www.jirikoutny.cz/skoleni-symfony
Ach ty formuláře
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.
Re: Ach ty formuláře
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.
Re: Ach ty formuláře
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.
Re: Ach ty formuláře
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 :-)
Re: Ach ty formuláře
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.
Re: Ach ty formuláře
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
Re: Ach ty formuláře
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.
Ad nevýhody
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
Re: Ad nevýhody
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.
Re: Ad nevýhody
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
Re: Ad nevýhody
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.
Ja som naopak s formularmi v Symfony2 velmi spokojny, inak dobry clanok! Som rad, ze tento skvely framework podporuje aj niekto od nas.
Koukám, že Nette vede, pojďme mu pomoci s propagací!
Ří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.
Re: Koukám, že Nette vede, pojďme mu pomoci s propagací!
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.
Re: Koukám, že Nette vede, pojďme mu pomoci s propagací!
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.
Re: Koukám, že Nette vede, pojďme mu pomoci s propagací!
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 :)
Re: Koukám, že Nette vede, pojďme mu pomoci s propagací!
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á :-)
Re: Koukám, že Nette vede, pojďme mu pomoci s propagací!
Ž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. :/
Re: Koukám, že Nette vede, pojďme mu pomoci s propagací!
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.
Re: Koukám, že Nette vede, pojďme mu pomoci s propagací!
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.
Re: Koukám, že Nette vede, pojďme mu pomoci s propagací!
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.
Re: Koukám, že Nette vede, pojďme mu pomoci s propagací!
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.
Re: Koukám, že Nette vede, pojďme mu pomoci s propagací!
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ý.
Re: Koukám, že Nette vede, pojďme mu pomoci s propagací!
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í.
Re: Koukám, že Nette vede, pojďme mu pomoci s propagací!
Díky. Kód jsem nestudoval, ale vypadá to celkem slibně. Na nějakym projektu to vyzkouším.
Parádní článek
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á.
Re: Parádní článek
Díky, napíšeme společně seriál? ;)
Re: Parádní článek
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 :)
Re: Parádní článek
To je rozhodně výzva! 8-)
Sila Symfony vs zdroje studia
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.
Re: Sila Symfony vs zdroje studia
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).
Re: Sila Symfony vs zdroje studia
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.
Re: Sila Symfony vs zdroje studia
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é :(
symfony sa nechyta
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
Re: symfony sa nechyta
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!
Re: symfony sa nechyta
> 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
Re: symfony sa nechyta
> 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 :)
Re: symfony sa nechyta
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 :)
Re: symfony sa nechyta
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.
Re: symfony sa nechyta
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ť“
Re: symfony sa nechyta
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.
Re: symfony sa nechyta
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?
Re: symfony sa nechyta
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í.
Re: symfony sa nechyta
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') }}
Re: symfony sa nechyta
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
Re: symfony sa nechyta
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.
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 :-))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.
A? Nejaký kód tam hádam máš? Na jednoduchý web/aplikáciu v Symfony ti postačí jeden bundle – je to len slovíčkarenie.
Re: symfony sa nechyta
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?
Re: symfony sa nechyta
hups,
tak uvediem iba hrefy pri tych odkazoch
sf2:
href=“{{ path(‚_demo_login‘) }}“
nette:
n:href=“demo:login“
Re: symfony sa nechyta
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.
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é
Re:
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ě.