Názory k článku
Nette Framework: adresářová struktura aplikace

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?

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

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

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

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

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

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"?

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.

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

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.

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

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.

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

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.

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

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.

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.

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

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

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.

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?

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

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.

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?

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

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

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

místo "pro načítání jednotlivých knihoven vlastní aplikace" má být "jednotlivých tříd"

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

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 Nette\Loaders\LimitedScope) je v souboru Nette\Loaders\LimitedScope.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 Nette\Loaders. Je to nepříjemný dočasný stav, netušil jsem, že se verze 5.3 o více než rok opozdí.

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.

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?

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.

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.

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.