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.

Zpět na článek

52 komentářů k článku Symfony2, těší mě!:

  1. Jaroslav Kubíček

    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.

    1. jkucharovic

      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.

    2. jirkakoutny

      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.

      1. jkucharovic

        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 :-)

        1. Jaroslav Kubíček

          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.

          1. jkucharovic

            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

          2. jirkakoutny

            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.

  2. jkucharovic

    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

    1. jirkakoutny

      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.

      1. jkucharovic

        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

        1. jirkakoutny

          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.

  3. patie

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

  4. David Grudl

    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.

    1. jkucharovic

      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.

      1. David Grudl

        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.

    2. jirkakoutny

      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 :)

      1. David Grudl

        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á :-)

        1. Vojtěch Kohout

          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. :/

          1. bene

            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.

    3. jkucharovic

      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.

    4. honzamarek88

      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.

    5. maryo

      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ý.

        1. maryo

          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.

  5. vencza

    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á.

      1. Martin Hlaváč

        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 :)

  6. wandal

    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.

    1. jirkakoutny

      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).

      1. wandal

        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.

        1. radek.zilka.3

          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é :(

  7. martin.bazik

    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

    1. jirkakoutny

      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!

      1. martin.bazik

        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

        1. Martin Hasoň

          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 :)

          1. martin.bazik

            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 :)

            1. Jan Machala

              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.

        2. jkucharovic

          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ť“

          1. jkucharovic

            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.

          2. David Grudl

            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?

            1. Martin Hasoň

              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í.

            2. jkucharovic

              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') }}

          3. martin.bazik

            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

            1. jkucharovic

              Re: symfony sa nechyta

              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.

        1. martin.bazik

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

          nette:
          n:href=“demo:login“

      2. David Grudl

        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.

  8. 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é

    1. bene

      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ě.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=9097