Vlákno názorů k článku
Nette Framework: adresářová struktura aplikace

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

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.

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

Stačí dodržovat některé z pravidel, které jsem psal na http://v6ak.profitux.cz/clanky/jak-by-mel-vypadat-kazdy-autoload.php (ne všechny) a nebude problém - použijí se dva autoloady.