42 komentářů k článku Nette Framework: adresářová struktura aplikace:

  1. Mastodont

    Styl WordPressu
    Přičemž index.php nedelá nic jiného, než že definuje cesty k ostatním dvou adresářům app a libs (jako konstanty) a předá řízení zaváděcímu souboru aplikace.

    require APP_DIR . '/bootstrap.php'; // load bootstrap file

    Velmi podobně vypadá index.php i ve WordPressu. Čistě náhodou by ty dva soubory sloučit nešly?

    1. Martin Malý

      Re: Styl WordPressu
      Kdysi se slučovalo až tak extrémně, že v index.php bylo všecko… :) Jinak – je to otázka "rozumné meze", kterou má každý programátor někde jinde. IMO je rozumné mít v index.php opravdu jen to nejnutnější, tedy cesty, základní include a nějaké main(); Něco jako býval stub.obj, kdo ho pamatujete :)

      1. Mastodont

        Re: Styl WordPressu
        Ano, třeba sNews bývaly složeny z jednoho souboru – a jaká to byla pohoda. IMHO by v index.php mělo být vše, co je potřeba ve 100 % případů, čili například kontrola toho, zda je web ve stavu offline nebo online, kontrola blokace IP adresy (pokud je) apod. … mít 100 tříd ve 100 souborech je zběsilost :-)

        1. Martin Malý

          Re: Styl WordPressu
          Nejsme v rozporu… Tohle jsou věci, které (společně třeba s načtením application.ini) dávám do index.php taky

    2. Jiří Knesl

      Re: Styl WordPressu
      Jistě, sloučit by šly.

      Já třeba většinou mám bootstrap a index sloučený (když píšu v Zendu nebo Nette).

      Záleží na povaze frameworku, někde si skládáte strukturu sám (Zend, Nette) a tam si píšete index i bootstrap – pak to můžete sloučit (když k tomu máte důvod). V jiném frameworku (CakePHP, Code Igniter) dostáváte sktrukturu předvyplněnou a tam se bootstrap.php hodí.

    3. David GrudlAutor příspěvku

      Re: Styl WordPressu
      Sloučit by samozřejmě šly. Jen prostě aplikační kód raději vidím v adresáři s ostatním aplikačním kódem, než v document_root. Existují i ryze praktické důvody: mám třeba klienta, který provozuje cca desítku eshopů na různých doménách a subdoménách. Vnitřně jde o stále stejnou aplikaci, takže každý jednotlivý index.php definuje jen cesty a konstantu `SHOP_ID` pro rozlišení obchodu a volá bootstap.php, který už je pro všechny shopy společný.

  2. Martin Malý

    Autoloader
    Trošku kacířskou otázku položím: Nette je malý a jednoduchý framework, že? Proč je tedy jeho autoloader takto mocný, indexující a cachující? Nevystačil by si s autoloaderem postaveným na jednoznačné jmenné konvenci, kdy z názvu třídy lze odvodit jméno souboru i jeho umístění? Či jinými slovy: Proč zrovna tady nedrží princip "convention over configuration"?

    1. aprilchild

      Re: Autoloader
      Ja bych rekl, ze je to tak napul. Na jedne strane to umozni vytvorit si vlastni konvenci, mit v jednom souboru vice trid a suplovat tim spise funkci "modulu". Je to otazka vkusu, ale nekomu vyhovuje vice abstrakce "soubor = modul" oproti "soubor = trida" (dekujeme Jave..). Ovsem je pravdou, ze tahle benevolence povede u neporadnych programatoru k totalnimu chaosu v pojmenovani a lepe by se hodila konvence jednoznacna. Idealne bych asi pouzival konvenci, soucasny zpusob by musel byt nekde explicitne povolen.

      Mozna lepsi vice souboru, nez neporadek pri prebirani ciziho projektu.

      1. Martin Malý

        Re: Autoloader
        Jmenná konvence nebrání mít v jednom souboru víc tříd… jen se musí podobně jmenovat. :)

    2. David GrudlAutor příspěvku

      Re: Autoloader
      Framework jako takový RobotLoader nepotřebuje. Buď se načte v kompaktní/minimalizované formě a pak je načtený celý hned a nepotřebuje žádný autoloader, nebo se načte ve své plné formě a pak inicializuje vlastní NetteLoader, který z názvu třídy "odvodí" jméno souboru (platí jen pro všechny třídy frameworku).

      Takže RobotLoader je tu pro

      – knihovny (často třetích stran)
      – samotnou aplikaci

      A právě v těchto případech nelze vyžadovat nějakou jednotnou konvenci. U knihoven třetích stran je to jasné, u aplikace samotné je to dáno především neexistencí jmenných prostorů; nesetkal jsem se s nikým, kdo by třídy aplikace pojmenovával jako Model_Automat nebo Presenters_Front_HomepagePresenter.

      1. Martin Malý

        Re: Autoloader
        Knihovnám třetích stran lze udělat wrapper třídu, která dodrží jmennou konvenci, načte si vše co je potřeba a odkud je to potřeba, a hlavně funguje konzistentně se zbytkem systému. Ano, je to vrstva navíc, ale není to tak tragické; navíc si člověk pro knihovny třetích stran často dělá nějaké "přiohýbací" metody, takže se mu ten wrapper stejně hodí.

        "Nesetkal jsem se s nikým, kdo by třídy aplikace pojmenovával…" – a to já zas jo. Právě proto je to "jmenná konvence", protože určuje, jak se třída má jmenovat. "Donutit" programátora pojmenovat třídu jako Model_Automat sice omezuje jeho kreativitu ve vymýšlení názvů, ale oba víme, že kreativita zrovna tady občas i škodí – právě i z důvodu (dosavadní) neexistence jmenných prostorů. ;)

        1. David GrudlAutor příspěvku

          Re: Autoloader
          RobotLoader se dá považovat za takový univerzální wrapper. Spousta cest vede do Říma. RobotLoader je prostě jednou z nich.

          ad jmenné konvence: v Nette je ještě SimpleLoader. Ten právě třídu Model_Automat načte ze souboru Model/Automat.php.

          1. Martin Malý

            Re: Autoloader
            OK. Já se ptám proto, že jsem se při vývoji vlastního FW propracoval právě od systému "prohledám-a-najdu" ke "konvenci vím-kde-to-hledat" a připadá mi pohodlnější, rychlejší a víc sexy. Takže teď dumám, jestli jsem nepřehlídnul nějaký problém…

        2. v6ak

          Problém vrstvy navíc
          Ne, že by mě vrstva navíc nenapadla, ale považuju to za špatné řešení. Nevím, co si pod tím přesně představujete, ale v každém případě to způsobí jednostrannou nebo žádnou kompatibilitu s ostatními.
          Samozřejmě, to se týká jakéhokoli wrapperu, který neimplementuje původní rozhraní, vč. Dibi. Nezavrhuju všechny wrappery, ale pouze ty, kde přínos není dostatečný k ospravedlnění ztráty kompatibility.

          1. Martin Malý

            Re: Problém vrstvy navíc
            Tak, že do řetězce "Framework – 3rd party knihovna" je přidán mezičlánek "Framework – Wrapper pro knihovnu – 3rd party knihovna". Wrapper tu má roli prostředníka, který odstiňuje aplikačního programátora od API knihovny a "zapouzdřuje" ji do formátu a zvyklostí podle zbytku frameworku, tedy tak, že "navenek" dodržuje např. tu jmennou konvenci a (např.) usnadňuje změny kódu při změně knihovny. Příklad: Používám CAPTCHA. Udělám si tedy "wrapper" třídu, která se tváří jako integrální součást frameworku a poskytuje metody tak, jak je uživatel frameworku zvyklý, ovšem "uvnitř" zajišťuje funkcionalitu voláním nějakých knihoven třetí strany (recaptchalib např.)

            1. v6ak

              Re: Problém vrstvy navíc
              To je ta přínosnější i drastičtější varianta.
              Ještě jsem zapoměl na jedno měřítko: práce cizích knihoven s tím. Třeba v případě CAPTCHA knihoven:
              1. Mohou implementovat jedno rozhraní => přínos v polymorfismu
              2. Moc knihoven s nimi nebude pracovat
              Jako protiklad bych uvedl wrapper pro kolekce, který by měl vlastní rozhraní. Jakkoli by to bylo přínosné (IMHO minimálně), bylo by to nekompatibilní s čímkoli ostatním.

              1. Martin Malý

                Re: Problém vrstvy navíc
                Mám intenzivní dojem, že každý mluvíme o něčem jiném. Každopádně u čtvrtého "knihoven" jsem se ztratil, nechápaje kdo s kým nebude pracovat a proč. Řekl bych, že to asi není podstatné a že už zabíháme do detailů, do nichž jsem zabřednout nechtěl.

            2. Jiří Knesl

              Re: Problém vrstvy navíc
              A to je právě ono. Třeba se mi nepodařilo skloubit do sebe autoloader DomPDF a Zend Frameworku. A přitom stačí použít Nette RobotLoader, který tento problém řeší i bez wrapperu.

              1. Martin Malý

                Re: Problém vrstvy navíc
                Pokud má knihovna vlastní nekompatibilní autoloader, pak opravdu můžu jmennou konvenci zahodit. Ale na začátku tohoto vlákna jsem se ptal, proč David použil toto řešení v Nette, nikoli "co dělat, když má includovaná knihovna vlastní autoloader". Pokud chci připojit obrovskou knihovnu s vlastním autoloaderem do svého FW, tak je IMHO ideální řešení zapojit pořádně hlavu a trochu se v tom povrtat, než se spoléhat na loadery…

  3. yeah

    RE: Nette Framework: adresářová struktura aplikace
    Skutečně se ukazuje, že jedním z největších zabijáků výkonu PHP je načítání velkého množství souborů (navíc nejsou-li absolutně adresováné).

    To by mělo být v php6 vyřešeno, ne? Ostatně tohle mi přijde pro php momentálně jako největší ostuda. Místo toho aby se řešil výkon tak se vymýšlejí ptákoviny, které do jazyka ještě dostat. A servery mezitim trpí třikrát větším náporem než musí…

    1. hejhula

      Re: RE: Nette Framework: adresářová struktura aplikace
      Máme rok 2014 a kde je PHP6? :-D
      Nikde…. Kdyby se ti amatéři vysrali na psaní pokusu o programovací jazyk, všem programátorům by se žilo lépe.

  4. Borek Bernard

    Víc konfigurací
    Jak Nette řeší víc konfigurací, např. jednu pro testovací prostředí a jednu pro reálný provoz?

    1. David GrudlAutor příspěvku

      Re: Víc konfigurací

      Způsob, který se uvádí jako doporučený, je konfigurace pomocí INI
      souboru. Ten má třeba následující strukturu:

      [common]
      set.date-timezone = "Europe/Prague"
      
      [production < common]
      database.driver = sqlite
      database.file = "%appDir%/models/db/demo.db"
      
      [development < production]
      database.profiler = TRUE

      Soubor definuje sekce production a development
      (znak < lze číst jako extends, v konfiguraci
      funguje dědičnost). Není-li nastaveno jinak, tak v produkčním režimu se
      načte konfigurace ze sekce production a ve vývojářském ze
      sekce development.

      1. Pavel Voska

        Re: Víc konfigurací
        To je pěkné řešení, nabízí se ale otázka, zda zpracováním INI souboru (předpokládám že při každém requestu) není zbytečný overhead, resp. zda by nějaké Array řešení nebylo u více zatížených aplikací rychlejší. Nebo se pletu a otevření, zparsování a interpretace syntaxe nemají na rychlost vliv?

        1. David GrudlAutor příspěvku

          Re: Víc konfigurací
          Ve starších revizích se zpracovaná konfigurace rovnou automaticky kešovala, ale rozdíl byl neměřitelný, takže jsem od toho upustil.

          1. Srigi

            Re: Víc konfigurací
            To je zaujimavy vysledok. V Docbook pre FW Symfony mozno najst az "chvalenkarstvo", ze ich FW konfiguraky kompiluje a je preto rychly.

            Ale Symfony vyuziva YAML konfiguraky a po celej zakladnej aplikacii su ich takmer dve desiatky, takze tam to asi zmysel ma.
            Kompiluju ich do PHP poli.

  5. Miloslav Pojman

    RE: Nette Framework: adresářová struktura aplikace
    Autoload je sexy, zvlášť jak je implementován v nette. Ve výsledku mi ale přijde kontraproduktivní, protože zdrojový kód ztrácí rychle na přehlednosti.

    Těch několik require_once na začátku každého souboru jasně popisuje závislosti – hned vidím co se používá a odkud se to bere. Pokud musím prohledat všechny soubory, abych zjistil odkud se symbol (ať je to globální proměná, funkce nebo třída) bere, je něco špatně.

    Snad každý jazyk používý nějaký konstrukt pro import, include nebo podobně. A zřejmě to nebude proto, že by jeho vývojáři neuměli napsat nějaký autoload.

    Mimochodem, proč všichni pro include používají nejrůznější konstrukce jako dirname(__FILE__) nebo NEJAKA_KONSTANTA_BASE_PATH, když tu máme include_path?

    1. David GrudlAutor příspěvku

      RE: Nette Framework: adresářová struktura aplikace

      Těch několik require_once na začátku každého souboru jasně popisuje
      závislosti – hned vidím co se používá a odkud se to bere.

      To je dobrý postřeh. Ale má smysl přehlednost vykoupit značným dopadem
      na výkon aplikace? Osvědčil se mi jiný postup. Nette je plně připravené
      na PHP 5.3 a jmenné prostory. S jejich použitím dojde k tomu, že se na
      začátku skriptů budou objevovat řady příkazů use (méně
      elegantní ASCII art deco ;-) ). Něco jako když se dnes člověk podívá na
      zdroják v C#. Na výkon to dopad nemá, ale jako dokumentační popis
      závislostí to funguje stejně dobře, ne-li lépe. No a já jsem si zvykl tyto
      příkazy, byť zakomentované, používat už v PHP 5.2.

      Snad každý jazyk používý nějaký konstrukt pro import.

      Ano, use je velmi podobné jako import.

      Mimochodem, proč všichni pro include používají nejrůznější
      konstrukce jako dirname(__FILE__) nebo NEJAKA_KONSTAN­TA_BASE_PATH, když tu
      máme include_path?

      Na include_path teoreticky není 100% spoleh, je to pomalé a vyžaduje to od
      vývojáře, který chce použít knihovnu, aby správně include_path nastavil.
      Dovedu si představit, že třeba u takového Texy by půlka vláken na fóru
      byla: „nejede mi to“ s odpovědí „nastavil jsi správně
      include_path“?

      1. v6ak

        RE: Nette Framework: adresářová struktura aplikace
        Dodal bych, že v Javě není import povinný – při odkázáni se na třídu je možné uvést namespace a při práci s návratovou hodnotou ani to. V php to asi bude podobně.
        V Javě je při použití více tříd se stejným názvem někdy potřeba použít namespace.Třída, v php se tomu snad půjde vyhnout přejmenováním. Ale těžko se vyhnu přímo práci s návratovou hodnotou. Ale to zas tak nevadí.
        Jinak java v podstatě má autoloading.
        Lehké ot: jak php 5.3 vyřeší odkazy na ReflectionClass? Bude možné něco jako Třída.class, nebo bude potřeba použít řetězec s celou cestou a případnými problémy při refaktoringu?

      2. Miloslav Pojman

        RE: Nette Framework: adresářová struktura aplikace

        To je dobrý postřeh. Ale má smysl přehlednost vykoupit značným dopadem na výkon aplikace?

        Co jsem sledoval nějaké diskuse ohledně vývoje zend frameworku, tak ten dopad na výkon je skutečně znatelný. Ale:

        • Nette má kompaktní verzi, kterou použiju, pokud mi jde o výkon, kde žádné include nebo autoload neřeším.
        • Když použiju knihovnu třetí strany, ta si řeší includy po svém a na autoload stejně nedojde
        • Pokud si napíšu vlastní knihovnu, nechci aby byla závislá na nette a jejím autoloadu
        • Vlastní skripty pro jednotlivé stránky jsou zpravidla jednoduché a jedou vždy po stejné koleji, takže zbytečné includy moc nehrozí. Pokud používám nějakou složitou knihovnu, kterou využiju jen občas, můžu v jejím připadě includovat až když ji opravdu potřebuji.

        Osvědčil se mi jiný postup. Nette je plně připravené na PHP 5.3 a jmenné prostory. S jejich použitím dojde k tomu, že se na začátku skriptů budou objevovat řady příkazů use (méně elegantní ASCII art deco ;-) ). Něco jako když se dnes člověk podívá na zdroják v C#. Na výkon to dopad nemá, ale jako dokumentační popis závislostí to funguje stejně dobře, ne-li lépe. No a já jsem si zvykl tyto příkazy, byť zakomentované, používat už v PHP 5.2.

        Ale kolik vývojářů používajících nette dodržuje stejné konvence?

        Ať si každá knihovna nebo framework uvnitř používá co chce. Nelíbí se mi ale vydávat autoload na všechno za standardní řešení (jak se může po přečtění zdát začínajícímu programátorovi). Autoload má v mnoha případech smysl, ale každý vývojář by měl vědět proč a kde ho použít.

        Na include_path teoreticky není 100% spoleh, je to pomalé a vyžaduje to od vývojáře, který chce použít knihovnu, aby správně include_path nastavil. Dovedu si představit, že třeba u takového Texy by půlka vláken na fóru byla: „nejede mi to“ s odpovědí „nastavil jsi správně include_path“?

        Tohle jde například řešit pomocí souboru TexyForDummies.php, který nastaví příslušnou include_path a naincluduje Texy.php

        Pokročilý vývojář si nastaví include_path jak potřebuje a použije standardní řešení.

        U texy je to asi jedno, beztak můžu použít kompaktní verzi, ale používat deset knihoven, kde si každá řeší includovaní souborů nějakým obskurním způsobem je peklo. Autor každé z těch knihoven se bude hádat, že jeho řešení je nejlepší a těžko říct kde je pravda.

        Když už jsem si jednou jsem si vybral php, tak preferuji řešení, které mi nabízí.

        1. David GrudlAutor příspěvku

          RE: Nette Framework: adresářová struktura aplikace

          Možná trošku odbočujeme od tématu. RobotLoader je především nástroj
          pro načítání jednotlivých knihoven vlastní aplikace. Ta už je na Nette
          Frameworku postavena, tudíž závislost na RobotLoaderu je v pořádku.
          Načítání jiných knihoven je jen
          možný/volitel­ný/vedlejší/pří­jemný efekt.

          Nelíbí se mi ale vydávat autoload na všechno za standardní
          řešení.

          Mně také ne.

          Tohle jde například řešit pomocí souboru TexyForDummies.php, který
          nastaví příslušnou include_path a naincluduje Texy.php. Pokročilý
          vývojář si nastaví include_path jak potřebuje a použije standardní
          řešení.

          Ale přece include_path není „standardní řešení“, nebo alespoň
          není „standardnější“ než „standardní“ autoloading. Prostě je to
          jedna z cest. A pokud mohu aplikaci napsat tak, aby její funkčnost
          nebyla podmíněna správným nastavením určité direktivy,
          tak ji
          tak napíšu. Nerozumím snaze mě přesvědčit, abych tam uměle tuto
          závislost vložil ;)

          1. David GrudlAutor příspěvku

            RE: Nette Framework: adresářová struktura aplikace
            místo "pro načítání jednotlivých knihoven vlastní aplikace" má být "jednotlivých tříd"

          2. Miloslav Pojman

            RE: Nette Framework: adresářová struktura aplikace

            Nelíbí se mi ale vydávat autoload na všechno za standardní řešení.

            Mně také ne.

            Ani tě z ničeho takového nepodezřívám. Proto jsem psal „jak se může po přečtění zdát začínajícímu programátorovi“. Viz třeba „Sbohem všem require dej“ Samozřejmě je to nadsázka, ale článek mi tak vyznívá.

            Ale přece include_path není „standardní řešení“, nebo alespoň není „standardnější“ než „standardní“ autoloading. Prostě je to jedna z cest. A pokud mohu aplikaci napsat tak, aby její funkčnost nebyla podmíněna správným nastavením určité direktivy, tak ji tak napíšu. Nerozumím snaze mě přesvědčit, abych tam uměle tuto závislost vložil ;)

            Můje první větička o include_path byla trochu mimo téma. Nebyla to vítka proti Nette ani Texy. Jenom takový postesk, proč všichni používájí require_once SOME_CONSTANT . „foo/bar.php“ místo aby jednoduše přidali SOME_CONSTANT do include_path.

            Souhlasím, že třeba závislost Texy na include_path je zbytečná.

            Na druhou stranu includy v nette se mi už moc nelíbí. Asi je to otázka osobní preference, ale uvedu příklad (RobotLoader.php, přišel mi první pod ruku):

            require_once 'Nette/Framework.php'; by mi přislo mnohem hezčí a hlavně přehlednější než require_once dirname(__FILE__) . '/../Framework.php';

            Když se podívám dál, používají se v tom souboru třídy LimitedScope nebo Environment. Kde je mám hledat? Je zaručeno, že už byly includovány? Je tam schovaná závislost, kterou neobjevím, dokud neprojdu celý zdroják. Přitom zrovna závislost na Environment je hodně důležitá.

            1. David GrudlAutor příspěvku

              RE: Nette Framework: adresářová struktura aplikace
              On v tom systém je, dokonce velmi přísný. Ale ten nemusí nikdo kromě komitujících znát. Z hlediska čtenáře kódu totiž stačí vědět, že třída LimitedScope (přesněji NetteLoadersLimitedScope) je v souboru NetteLoadersLimitedScope.php. Tady se pravda naráží na smutnou skutečnost, že Nette je připravené na jmenné prostory a ve zpětněkompatibilním režimu není zřejmé, že LimitedScope je ve jmeném prostoru NetteLoaders. Je to nepříjemný dočasný stav, netušil jsem, že se verze 5.3 o více než rok opozdí.

    2. Jakub Vrána

      RE: Nette Framework: adresářová struktura aplikace

      Direktiva include_path má tu nevýhodu, že je nejednoznačná. Když napíšu include "compatibility.php", tak záleží na tom, v kterém adresáři z include_path se soubor najde jako první. Knihovna by si neměla dovolit direktivu sama přenastavit, protože když se přidá na začátek, tak mi přeplácne adresáře, ze kterých bych chtěl stejnojmenné soubory vkládat já, a když na konec, tak zase nemá jistotu, že se na ni dostane. Tím pádem je knihovna závislá na nastavení zvenku, což je otrava (a pořád zůstává problém se stejně pojmenovanými soubory v různých knihovnách).

      Nezávislost na include_path je výhoda, nikoliv slabina.

      1. Miloslav Pojman

        RE: Nette Framework: adresářová struktura aplikace
        Předpokládám, že svoji knihovnu mám v nějaké adresáři, takže píšu třeba include "moje_knihovna/compatibility.php" a konflikt by neměl nastat.

        Aby si knihovna přidávala něco do include_path byl můj úlet, tak opravdu ne.

        Dokud knihovna nemá žádné závislosti, tak trik s dirname funguje skvěle. A asi není důvod se ho pro includy v rámci knihovny vzdávat. Krom toho, že je to malinko méně přehledné, ale to je subjektivní. I když klukům v zendu to přijde asi stejně.

        Neřeší mi to ale externí závislosti. Mám pro kažkou knihovnu kterou používám definovat nějakou konstantu?

        Stejně jako každý jazyk má nějaký import nebo include, tak snad každý má nějakou importpath, classpath nebo podobně. Proč se jí zrovna v php bránit?

        1. Jakub Vrána

          RE: Nette Framework: adresářová struktura aplikace

          Takže při adresářové struktuře libs/Nette by v include_path byl adresář libs? To mi ale zabraňuje si adresář pojmenovat jinak, třeba Nette-0.8. Opravdu nevidím žádný způsob, jak se vevnitř knihovny bez výpočtu cesty obejít.

          V aplikaci, která knihovny využívá, mám svobodu – můžu používat relativní cesty, konstanty nebo klidně i include_path, ale vnitřek knihovny by se na to neměl spoléhat.

          1. Miloslav Pojman

            RE: Nette Framework: adresářová struktura aplikace
            V knihovně zpravidla nejsou jenom zdrojáky, ale často také testy, nějaké demo, readme, lincense, atd… Samozřejmě většinu nepotřebuji, ale přinejmenším při vývoji chci ke knihovně i ty věci okolo.

            Takže v adresáři lib (kterých může být několik) mám např. Nette-0.8 a v něm mimojiné podadresář Nette nebo případně source/Nette (jak to stáhnu). V include path pak Nette-0.8 respektive Nette-0.8/source. Ono neuškodí mít na jednom místě sepsané všechny použité knihovny.

            1. Jakub Vrána

              RE: Nette Framework: adresářová struktura aplikace
              Vedle aplikace chci mít pouze samotnou knihovnu, tedy jenom adresář Nette. Ostatní věci okolo (testy, příklady, licenci, ikonky) mohu používat při vývoji, ale pro nasazení aplikace to není potřeba a nemělo by to tam tedy ani být.

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=2988