Je tohle DI/DI container? Dělám to správně?

No já myslím, že o Environmentu se ví… a jeho existence pokud se nepletu zůstává jen kvůli zpětné kompatibilitě. A taktéž jeho používání se nedoporučuje. A tuším, že jsem i někde viděl, že je v plánu ho kompletně odstranit. ;-)

HosipLan napsal(a):

Kvůli dvěma metodám jsi psal stovky řádků „na koleni“?

No co, mrknu na syntax, líbí se mi, zajímá mě, jak něco takového funguje, tak si to rozeberu a zkusím naprogramovat a třeba i trošku líp, pokud je to možné.

>

Nette se snaží magie zbavovat. Například tyhle dvě metody se řeší zde.

Super
EDIT: Ještě myšlenka… proč bych tedy měl chtít framework, který je nejdřív magický a pak magii očesává? Není lepší mít framework, který se snaží už od základu magii předcházet? Jenom tak říkám…

>

Co když nechci použít CSRF protekci?

Tak ji nepoužívej

Proč vytrháváš z kontextu abys pak mohl odpovídat stylem „na hloupou otázku hloupá odpověď“? Honíš si ego nebo co..?
Ve formu můžu občas potřebovat session, kvůli obraně proti CSRF, ale třeba tu protekci ani nevyužiju. Je lepší (čistší, kvalitnější, přečti si to jak chceš) session vkládat už do konstruktoru, byť třeba zbytečně, nebo je lepší jej chtít v metodě protect? Mám na mysli jestli se třeba nepovažuje za prasárnu když nastavuju závislosti v metodě, která má dělat i něco jiného (tzn. není to setter!).. no nic, možná se ptám blbě, ale vola ze mě dělat nemusíš.

>

Obojí je DI Container, podstatné je použití. Protože i DI Container se dá použít jako service locator. A v presenteru se DIC v současné době používá jako service locator.

OK tak jestli už (snad) dobře chápu, tak DIC je něco, co mi skládá služby podle configu a service locator je rozhraní, přes které si je z DIC tahám?

Né že se ti to nelíbí, ty jsi to zkrátka nepochopil :) To je celé. Neon je téměř dokonalý.

Pro mě je téměř dokonalé to, co mi umožní psát méně kódu. Abych pro popsání pár služeb musel na každém druhém řádku psát „class:“, mi prostě téměř dokonalé nepřijde. Možná jsou jiné způsoby, ale nevšiml jsem si. Chci čistě jen popsat závislosti. Co nejúspornějším a nejkratším zápisem. Tady mi neon prostě nepomůže, protože neon počítá nejen se službami, ale i s továrnami, konfigurací PHP a já nevím s čím ještě (souhlas že pokud se chceš vyhnout psaní PHP, neon je vcelku fajn…) a prostě se musí popsat co to je. Zároveň ale taky chci, abych měl nad službami maximální kontrolu. Co mi přijde že Nette dělá je, že si sám nadefinuje několik základních služeb (request, session atd), aniž bych je popsal někde v konfiguraci DIC. Když chci použít vlastní třídu, musím přemýšlet, jak to přepsat a mít jistotu, že tam je skutečně ta moje služba. Myslím, že v případě více projektů nemám problém si svůj seznam nejčastěji používaných služeb prostě zkopčit, než je mít někde skryté. Opět mi to přijde takové nečisté.

Z toho, co o DI zatím vím, si myslím, že toto moje řešení je DI kontejner využívající lazy-loading, kterému prozatím chybí setter injection (loginForm.renderer = loginFormRenderer;).

Tohle je dost mimo.

Co je mimo?
Pseudo-kód psanej z hlavy:

<?php
class Z {
	private $config = array();
	private $services = array();

	public function __construct($conf) {
		$this->config = $this->parseConfig($conf);
	}

	public function & getService($name) {
		if(isset($this->services[$name])) {
			return $this->services[$name];
		}
		if(!isset($this->config[$name])) {
			// error - služba není v configu
		}

		$this->createService($name);
		return $this->services[$name]);
	}

	public function &__get($name) {
		return $this->getService($name);
	}
	...
?>

Když službu vytvořím až ve chvíli, kdy si ji vyžádám (např. připojení k databázi se provede až ve chvíli, kdy zkusím provést dotaz), tak se to snad nazývá lazy-loading, pokud se nepletu..

>

Tohle s DI nemá vůbec nic společného. To co popisuješ je konfigurace DIC.

Tak pardón za špatné pojmy. Jak říkám – DI se zrovna moc dlouho nevěnuji a snažím se to nějak pochopit.

Kdykoliv tu čtu nějaké tutoriály … Sakra PROČ? Ty služby jsou jenom pitomý obyčejný objekty! S objektem dělám akorát tohle: 1) vytvořím, 2) zavolám metodu, 3) přečtu nebo změním property, 4) pošlu ho někam (třeba kam slunce nesvítí).

A pointa?

Sakra PROČ? Když jde vesměs vše zjednodušit na obyčejnou třídu, která si akorát vyžádá nějaké závislosti a tím to pro mě končí. Já s tím nepotřebuju dělat další čachry, dělat si továrny apod. Proč např objekt Http\Request má statickou metodu, která se jmenuje tuším createHttpRequest (což je továrna, která vrací instanci své třídy)? Prostě udělám new Http\Request a tím to pro mě hasne. Konstruktor už si to obslouží sám. Navíc mě továrna může nutit dělat věci, které nechci (například třídě Article vytvořit veřejnou metodu setId).

Jsi mimo, tohle naprosto nestačí. A až budeš programovat déle, tak to pochopíš. Jednou narazíš.

Čemu říkáš déle? Hádám že 8 let u procedurálního programování nebereš, podle míry arogance, s jakou píšeš. Nicméně měl bys vzít v potaz, že dřív bylo OOP v PHP naprosto nepoužitelný. A OOP dělám tak rok, zatím se ho tedy pořád spíš učím a snažím se zbavit svých prasáckých zvyků z procedurálního programování.

Nechápeš pointu. DI nemá nic společného s konfigurací.

Konfigurace DI nemá nic společného s DI. Programování v PHP nemá nic společného s PHP. Prodej aut nemá s auty nic společného… myslíš to vážně?

Popsal jsem tři služby a už mě to fakt neba…

Kdybys nebyl začátečník, tak teď bych byl asi sprostý.

Tak zkus nebýt sprostý a třeba mi ukázat nějaké fakt jednoduché, rychlé a hezky vypadající řešení, a prosím co jeden řádek, to jedna služba, a ať nemusím taky řešit nějaké tabulátory, já si přece sám určím, jestli chci mít argumenty odtabnuté někam doprava, kde se mi nemíchají s názvy tříd, nebude mi to diktovat žádný formát :)

Tak zkus udělat něco nesobeckého a místo vykrádání Nette se zapoj a zkoušej vymýšlet jak ho zdokonalit.

A co asi dělám? Popsal jsem tu hromadu věcí, co mi vadí, u některých jsem se dozvěděl, že se o nich ví, ale řešení pořád nikde a než to bude, napíšu si to radši celý sám, abych to mohl začít konečně používat. Upřímně – zbavení se těch dvou statických metod v Nette by byla práce na 10 minut (i s testováním) – jedno si vezmu v konstruktoru a uživatel si prostě zvykne, že místo new Form() napíše new Form($context->request); a druhé se hodí do addProtection nebo jak se ta metoda jmenuje v Nette (protect je kratší a lépe zapamatovatelné, addProtection ve mně evokuje pocit, že těch protekcí můžu přidat kolik chci nebo dokonce zavolat removeProtection). Ale řešení ještě oficiálně venku není, že? Škoda…
A je moc hezké mluvit o vykrádání u opensource projektu ;) Docela problém pro tebe je to, že usiluji o maximální množství mého vlastního kódu. Co si pamatuji, že jsem z Nette vykradl, tak je seznam nepárových html tagů v knihovně Html a to je vše. Jsem inspirován Nette, můj FW používá podobnou namespace strukturu jako Nette (fakt je vykrádání když objekt session hodím logicky do namespace http?), ale má jiný kód a trošku jinou logiku práce (takovou trochu víc typu „udělej si sám“ namísto „nech to bejt a já to nějak magicky za tebe vyřeším, vůbec neřeš jak funguju, hlavně že funguju“, což je přesně to, jak na mě Nette místy působí). Tak mi řekni, co jinýho mám dělat, když se mi něco v Nette líbí a chci to používat, ale nechci k tomu celej FW?

Editoval Zax (6. 8. 2012 20:49)

Není lepší mít framework, který se snaží už od základu magii předcházet? Jenom tak říkám…

Jej.. ty píšeš kód vždy na první dobrou?

Je lepší session vkládat už do konstruktoru, byť třeba zbytečně, nebo je lepší jej chtít v metodě protect?

Setter injection je regulérní DI praktika. Jde o účelnost. Tedy pokud víš, že vždy session nevyužiješ, tak je setter vhodnější.

Obojí je DI Container, podstatné je použití. Protože i DI Container se dá použít jako service locator. A v presenteru se DIC v současné době používá jako service locator.

OK tak jestli už (snad) dobře chápu, tak DIC je něco, co mi skládá služby podle configu a service locator je rozhraní, přes které si je z DIC tahám?

Ne. Správně bys vůbec na DIC neměl sahat. Proto je teď v novém Nette tenhle kód. Zavolá všechny metody nad presenterem, které začínají na inject a podle typehintu ti tam přes autowire předá služby.

Pro mě je téměř dokonalé to, co mi umožní psát méně kódu.

A o tom je Neon.

Abych pro popsání pár služeb musel na každém druhém řádku psát „class:“, mi prostě téměř dokonalé nepřijde. Možná jsou jiné způsoby, ale nevšiml jsem si.

Správně, nevšiml:

services:
	foo: Foo
	bar: Bar

Pokud víc nepotřebuješ, dá se to psát i takhle. Btw, umí tvoje verze DI Containeru autowire?

Tady mi neon prostě nepomůže, protože neon počítá nejen se službami, ale i s továrnami, …

Proč říkáš věci, které nevíš jistě? A ještě to podáváš jako fakt. Proč to děláš?

Zároveň ale taky chci, abych měl nad službami maximální kontrolu.

To snad nemáš?

Co mi přijde že Nette dělá je, že si sám nadefinuje několik základních služeb (request, session atd), aniž bych je popsal někde v konfiguraci DIC.

Ano, to přesně dělá. A má k tomu hodně dobrý důvod. Například to, že když chceš Nette začít používat, nemusíš si v configu vypisovat úplně všechny služby, co potřebuje pro život. Tohle je tedy naprosto v pořádku. A ještě ti povím fígl, jde to úplně vypnout ;)

Když chci použít vlastní třídu, musím přemýšlet, jak to přepsat a mít jistotu, že tam je skutečně ta moje služba.

Nemusíš přemýšlet jak to přesat. Nad čím jako chceš přemýšlet? Prostě se podíváš do kódu, jak se ta služba jmenuje.

Myslím, že v případě více projektů nemám problém si svůj seznam nejčastěji používaných služeb prostě zkopčit, než je mít někde skryté. Opět mi to přijde takové nečisté.

Není to nečisté. Je to naprosto v pořádku.

Z toho, co o DI zatím vím, si myslím, že toto moje řešení je DI kontejner využívající lazy-loading, kterému prozatím chybí setter injection (loginForm.renderer = loginFormRenderer;).

Tohle je dost mimo.

Co je mimo?

Mimo na tom je, že to nechápu.

Tak pardón za špatné pojmy. Jak říkám – DI se zrovna moc dlouho nevěnuji a snažím se to nějak pochopit.

Na pochopení je potřeba nejprve umět komunikovat a pokud chceš komunikovat správně, musíme si rozumět. A tohle je zrovna docela kritickej rozdíl.

Sakra PROČ? Když jde vesměs vše zjednodušit na obyčejnou třídu, která si akorát vyžádá nějaké závislosti a tím to pro mě končí.

To je přece v pořádku…

Já s tím nepotřebuju dělat další čachry, dělat si továrny apod. Proč např objekt Http\Request má statickou metodu, která se jmenuje tuším createHttpRequest (což je továrna, která vrací instanci své třídy)?

(Statická) továrna je naprosto regulérní programátorská praktika. To že to nepotřebuješ ty, neznamená, že to nepotřebují ostatní. A to že to nepotřebuješ ty, znamená že to nesmí mít ostatní? Takhle to totiž od tebe zní.

Prostě udělám new Http\Request a tím to pro mě hasne. Konstruktor už si to obslouží sám. Navíc mě továrna může nutit dělat věci, které nechci (například třídě Article vytvořit veřejnou metodu setId).

Od toho je to továrna. Pokud to tak nechceš, tak ji prostě nepoužiješ. To je problém, nepoužít nepovinnou továrnu?

Čemu říkáš déle? Hádám že 8 let u procedurálního programování nebereš, podle míry arogance, s jakou píšeš.

Ne neberu. Na škole jsem se učil assembler a opravdu to jako průpravu pro objektové programování nepočítám. Déle myslím to, až napíšeš několik plně objektových aplikací. U každého učení trvá jinou dobu.

Nicméně měl bys vzít v potaz, že dřív bylo OOP v PHP naprosto nepoužitelný.

Ano, bylo to hrozné, souhlasím.

A OOP dělám tak rok, zatím se ho tedy pořád spíš učím a snažím se zbavit svých prasáckých zvyků z procedurálního programování.

Však to je v pořádku, chválím.

Nechápeš pointu. DI nemá nic společného s konfigurací.

Konfigurace DI nemá nic společného s DI. Programování v PHP nemá nic společného s PHP. Prodej aut nemá s auty nic společného… myslíš to vážně?

Ano, smrtelně vážně. DI je technika. DI Container je nástroj. Konfigurace je taky technika. Na používání DI nepotřebuješ konfiguraci. Na používání DIC nepotřebuješ konfiguraci. Můžeš si služby vytvářet ručně

$container = new Nette\DI\Container();
$container->addService('foo', new Foo(new Bar));

Vidíš? Používám DI, používám DIC a nepoužívám konfiguraci.

Tak zkus nebýt sprostý a třeba mi ukázat nějaké fakt jednoduché, rychlé a hezky vypadající řešení, a prosím co jeden řádek, to jedna služba, a ať nemusím taky řešit nějaké tabulátory

Viz výše.

já si přece sám určím, jestli chci mít argumenty odtabnuté někam doprava, kde se mi nemíchají s názvy tříd, nebude mi to diktovat žádný formát :)

Neon je velice, velice, velice flexibilní formát. http://ne-on.org/ Ale nemůžeš mít jazyk bez pravidel, to nedává smysl.

Upřímně – zbavení se těch dvou statických metod … Ale řešení ještě oficiálně venku není, že? Škoda…

Víš, ony jsou tady věci jako zpětná kompatibilita, snadnost používání, čistota kódu.

Kdyby všechno v Nette bylo řešeno stylem „za 10 minut napíšu to první co mě napadne“ (ovšem musím uznat, že tvoje řešení v tomhle případě není úplně nejhorší), tak by nebylo tak kvalitní jako je teď.

A je moc hezké mluvit o vykrádání u opensource projektu ;)

Máš pravdu, měl jsem to napsat do uvozovek.

Docela problém pro tebe je to, že usiluji o maximální množství mého vlastního kódu.

Proč by tomhle byl problém?

Tak mi řekni, co jinýho mám dělat, když se mi něco v Nette líbí a chci to používat, ale nechci k tomu celej FW?

Možná jsem si to vzal trošku moc osobně. Na tohle jsem alergický, navíc když jsem viděl v tvé ukázce kódu výše úplně stejné namespacy, tak jsem trošku vytekl. Takže za to se ti omlouvám.

Každopádně mě mrzí, že vyvíjíš vlastní framework, když bys mohl používat Nette. Taky jsem se učil ze zdrojáků Nette a naučil jsem se z nich opravdu hodně, ale samotnou existencí Nette pro mě ztratilo smysl psát si framework (od nuly).

Když začneš využívat plnou sílu Nette, já ti garantuju, že nebudeš mít důvod z toho něco vyzobávat.

Ne. Správně bys vůbec na DIC neměl sahat. Proto je teď v novém Nette tenhle kód. Zavolá všechny metody nad presenterem, které začínají na inject a podle typehintu ti tam přes autowire předá služby.

Autowiring – opět něco pro mě šíleně magického. Ale to je asi jen o tom, co kdo preferuje. Nette je víc convention over configuration, zatímco já jdu spíš cestou configuration over convention, která na mě působí nejméně magicky, nejvíce logicky a tím pádem vlastně „správně“. Vše řádně popsané, ať v tom nejsou zmatky a nejasnosti. Toto je i odpověď na tvůj dotaz zda můj DIC umí AW.

Správně, nevšiml

To už je mnohem lepší :) Škoda, že v dokumentaci jsem se to nedočetl. Možná to tam je, ale já se začal ztrácet už ve chvíli, kdy jsem si četl o továrně DbFactory::createConnection. A kdyby se dalo bezpečně zbavit i toho řádku „services:“, bylo by to fantastické.

Proč říkáš věci, které nevíš jistě? A ještě to podáváš jako fakt. Proč to děláš?

Myslím, že to, co jsi citoval, jsem napsal pravdivě. V neonu popíšu víc než jen služby. Z toho usuzuji, že řádku „services:“ se zbavit nemůžu, aby z toho bylo jasné, že chci služby a ne třeba továrny. Sice debatuji nad jedním krátkým řádkem, ale vážně – co se stane, když ho tam zapomenu uvést? Zkousne to nebo vyhodí výjimku?

Ano, to přesně dělá. A má k tomu hodně dobrý důvod. Například to, že když chceš Nette začít používat, nemusíš si v configu vypisovat úplně všechny služby, co potřebuje pro život. Tohle je tedy naprosto v pořádku. A ještě ti povím fígl, jde to úplně vypnout ;)

Uznávám, že takhle „pro lidi“ je to asi fajn.

Mimo na tom je, že to nechápu.

Nechápeš lazy loading, ale o všem ostatním mě dokážeš poučit dokonale… tak já už fakt nevím..

Na pochopení je potřeba nejprve umět komunikovat a pokud chceš komunikovat správně, musíme si rozumět. A tohle je zrovna docela kritickej rozdíl.

V některých případech, zvlášť když jsem noob, bys mohl pochopit, co jsem měl na mysli, aspoň z kontextu. Řešíme něco nebo slovíčkaříme? Mně je taky fuk když někdo řekne že má v objektu funkci, pochopím, že má ve třídě metodu a obvykle za to nikoho nepeskuju. Chci pochopit a naučit se techniky DI, pojmy mi jsou víceméně fuk. Já to chci používat, ne o tom furt jenom klábosit.

Od toho je to továrna. Pokud to tak nechceš, tak ji prostě nepoužiješ. To je problém, nepoužít nepovinnou továrnu?

No, máš pravdu, továrny nejsou tak zlé. Singletony jsou horší (resp. jejich vynucování, které se v PHP řeší dost blbě). Ale továrny a singletony si jsou v jistých ohledech podobné.

Ne neberu. Na škole jsem se učil assembler a opravdu to jako průpravu pro objektové programování nepočítám. Déle myslím to, až napíšeš několik plně objektových aplikací. U každého učení trvá jinou dobu.

Tak to bude brzy.

Vidíš? Používám DI, používám DIC a nepoužívám konfiguraci.

Fajn, asi jsem to popletl. Osobně bych totiž klidně řekl, že tohle je taky konfigurace – akorát místo neonu jsi použil PHP. Typicky na jednom místě si takhle poskládáš kontejner a někde jinde ho používáš. Tam, kde ho skládáš, ho vlastně konfiguruješ (říkáš mu co je co, akorát jiným jazykem). Nicméně – možná nepotřebuji konfiguraci na samotné používání DIC, ale je potřeba pro podporu lazy loadingu.

<?php
$container->addService('db', new Mysql('localhost', 'root', 'heslo', 'dbname'));
?>

mi okamžitě vytvoří instanci, i když tu službu třeba ani nepoužiju. Zbytečně se připojuji k databázi a mrhám prostředky.

Neon je velice, velice, velice flexibilní formát. http://ne-on.org/ Ale nemůžeš mít jazyk bez pravidel, to nedává smysl.

Jazyk s pravidly ano, ale nerad stavím pravidla na bílých znacích. A z chybějících středníků mám vyloženě hrůzu, asi nějaké trauma ze střední, kde jsme dělali ve VB.NET. Taky mi třeba může vadit, že si musím pamatovat, že závislost předám pomocí zavináče (dolar po vzoru PHP by nešel?). Proč dvojtečka a ne rovnítko? Jsou to prostě takové ty drobnůstky, na které když si nedám pozor, tak mi mohou zkazit den. V neonu si prostě nemůžu dovolit třeba takovéto rozdělení na sloupečky pro vetší přehlednost:

db		= Z\Db\Mysql		('localhost','root','heslo','dbname');
url		= Z\Http\Url		();
request		= Z\Http\Request	(url);
router		= Z\Routing\Router	(request);
response	= Z\Http\Response	();
cookies		= Z\Http\Cookies	(request, response);

nebo možná třeba i můžu, ale nemůžu si tím být v první moment jistý, když vím, že neon na bílých znacích lpí.

Možná jsem si to vzal trošku moc osobně. Na tohle jsem alergický, navíc když jsem viděl v tvé ukázce kódu výše úplně stejné namespacy, tak jsem trošku vytekl. Takže za to se ti omlouvám.

Jak říkám: některé věci jsou v Nette takřka ideální, například ty namespace. Až s Nette jsem se naučil namespace aktivně používat a i když jsem přemýšlel nad nějakou lepší strukturou, nevymyslel jsem. Http, Forms, Templates… lepší názvy těžko někdo vymyslí.

Každopádně mě mrzí, že vyvíjíš vlastní framework, když bys mohl používat Nette. Taky jsem se učil ze zdrojáků Nette a naučil jsem se z nich opravdu hodně, ale samotnou existencí Nette pro mě ztratilo smysl psát si framework (od nuly).

Já ti to věřím, Nette je hezký počin, ovšem každému vyhovuje něco jiného. Nette bylo vyrobeno tak, aby „vyhovovalo všem“, což je bohužel přístup, který mně obvykle nevyhovuje. Narazím na něco, co se mi zdá zbytečně překomplikované nebo jinak „podivné“, chytnu se za hlavu, řeknu si „do p**ele PROČ? KDO to sakra vymyslel?“ – a radši si to celý napíšu sám. Oželím-li důsledné kontroly a házení výjimek, mám hotovo rychle. Navíc jde o můj kód, ve kterém se vyznám a vím, co si v něm můžu dovolit a co ne. Nette je prostě pro mě „cizí půda“ – cítím se nejistě, nevím, co na mě číhá za rohem za zradu apod. Zato když si vytvořím svou půdu, vím jak ji používat, co si dovolit.

Když začneš využívat plnou sílu Nette, já ti garantuju, že nebudeš mít důvod z toho něco vyzobávat.

Je právě problém, že to, co si vyzobávám, se mi líbí, ale zbytek už ne. Nette prostě vyžaduje určité trošku hlubší znalosti fungování a dávání si pozor („Pokud se rozhodnete minimalizovanou verzi použít, nahrajte nette.min.php do libs/Nette pod názvem loader.php“ ale já se rozhodl, že mě nebude framework komandovat, ale že já chci komandovat jej). Samozřejmě tím nechci říct, že chci fw používat jak tupý nevědomý pařez, jenom chci říct, že si opravdu nechci pamatovat každou blbůstku. Abych mohl nějaký framework používat 100% přirozeně a suverénně, musím se jej buď na 100% naučit, nebo si napsat svůj.

@Šaman: Nepochopils. Nechci si tu dělat žádnou reklamu, snažit se vychloubat nebo tak. Framework totiž nejspíš zůstane u mě jen pro moje osobní účely (můj kód není ani zdaleka tak kultivovaný, abych si troufl jej uvolnit). Chtěl jsem si hlavně ujasnit pár věcí typu, proč je tohle v Nette takhle a ne jinak, když ze všech stran slyším, že jinak by to bylo lepší. Taky jsem musel nějak představit svůj způsob konfigurace, abych se mohl zeptat, jestli to, co dělám, je DI nebo service locator či co a abych zjistil, jak se to liší od Nette (v čem to má to Nette lepší). Dokumentace je prostě taková zvláštní. Přečtu jednu stránku stokrát a pochopím prd, přečtu pár dalších, vrátím se zpátky a začne mi to docvakávat.

K tomu mému kritizování: vem si, že nad zdrojáky Nette jsem teď strávil poslední 2–3 měsíce, aniž bych samotné Nette vlastně pořádně použil. Kdykoliv jsem to zkusil, skončil jsem nad dokumentací, začal mě zmáhat WTF faktor a následoval vzdor typu „tak tohle dělat nebudu, vždyť ani nechápu jak to má jako fungovat“. Zkoumal jsem, co mi kde vadí a detekoval průšvih právě v té vrstvě mezi index.php a třídou, která se stará o plivání výstupu na obrazovku (a routování na mysli nemám, to jsem si vyřešil :) ). Zde mi prostě Nette vadí, skoro až překáží. Ukazuju svoje řešení, které jsem vymyslel, které mi vyhovuje a je pro mě naprosto přirozené a čekám, kdy mi někdo ukáže třeba i něco lepšího.

A zas sem se rozepsal… pardon :(

Editoval Zax (7. 8. 2012 8:55)

Tribute to Hosiplan :)

Nemyslím si, že si Zax nepíše nový framework, ale jen si přepisuje nesrozumitelné části Nette. Spíše se tě zeptám, pokud si se dostal do WTF stádia, kdy si nevěděl co a jak dál, proč jsi se nezeptal na fóru nebo na jabberu? Když něco chceš a nevíš jak na to, taky se na to vykašleš? Pokud máš nějaké otázky k Nette a máš skutečně zájem o to se dozvědět víc, zkus se zeptat tady na fóru nebo na jabberu a nebo mi klidně napiš na jabber či ICQ, co mám v profilu, pokud budu vědět, rád odpovím.

Newbiek napsal(a):

Nemyslím si, že si Zax nepíše nový framework, ale jen si přepisuje nesrozumitelné části Nette. Spíše se tě zeptám, pokud si se dostal do WTF stádia, kdy si nevěděl co a jak dál, proč jsi se nezeptal na fóru nebo na jabberu? Když něco chceš a nevíš jak na to, taky se na to vykašleš? Pokud máš nějaké otázky k Nette a máš skutečně zájem o to se dozvědět víc, zkus se zeptat tady na fóru nebo na jabberu a nebo mi klidně napiš na jabber či ICQ, co mám v profilu, pokud budu vědět, rád odpovím.

Ono mi stačí pokoušet se o config, abych narazil. Znechutil mě tím, že na mě křičel „missing section development“. Proč po mně config chce sekci development, když mu neupřesňuji žádné prostředí (druhý argument v addConfig)? Logicky když mu v druhém argumentu nic nedám, tak by neměl chtít žádnou sekci. Jenže né, on pan velký konfigurátor chce development sekci, dokud mu to výslovně nezakážu. Když takhle člověk narazí hnedka zezačátku, přestane mít chuť v tom cokoliv zkoušet, protože když mám problém už v prvním kroku, očekávám nějaký problém i v dalším. A abych těmto problémům předešel, udělám si to radši sám. Třeba zbastleně a ošklivě, ale hlavně aby obálka byla pěkná a práce s tím co nejjednodušší. A ano – píšu ho, kopíruju jen minimálně (například moje třída Html má 200 řádků, cca 6kB a jediné, na co jsem použil copy&paste, je pole $emptyElements, kdybych zkopčil celou knihovnu, musel bych ji okleštit o závislosti na Utils\Strings a Iterators\Recursor, což se mi fakt nechce, nechci pak řešit, co všechno se tím rozbije).

Šaman: Takže mám jít cestou že si sám napíšu půlku frameworku tím, že podědím a přepíšu třídy. To už je pro mě jednodušší napsat si to sám, než si ještě zjišťovat, jak se jmenují metody, které chci změnit :) A rozhodně netvrdím, že David neumí programovat, jenom říkám, že framework, který hlásá heslo „Při programování vám vychází vstříc a nepřidělává vrásky“, by mi měl skutečně vycházet vstříc a neotravovat s blbostma typu development section. Nic není černobílé – Nette je mocný výtvor a ve spoustě věcech vychází vstříc (kdyby ne, tak se v něm nerejpu a jdu třeba k nabobtnalému Zendu s dlouhými názvy tříd), ale občasnými drobnostmi mě dokáže frustrovat. Z dokumentace nevyčtu, proč se Nette chová zrovna takto (tam si totiž musím přečíst ještě o hromadě jiných věcí, které nejspíš nikdy nepoužiji, než se dopracuji k tomu, co hledám), z API reference jen částečně a nakonec se stejně musím pro jistotu dívat do zdrojáku a luštit. Psaní a vymýšlení je jednodušší.

A ještě jedna věc, hlavně k autowiringu: nechápu, co je předvídatelné a nemagické na tom, že mi něco samo skládá závislosti? Co když si přidám druhé připojení k databázi a na konec službu, která vyžaduje IConnection (třeba něco co mi obsluhuje přihlašování uživatelů proti databázi)? Které to připojení mi tam chytrý a předvídatelný autowiring dosadí? Nebo hodí výjimku? To jako pak musím přepisovat půlku configu když si chci přidat další připojení k databázi a autowiring končí? Není spíš autowiring jen výmluva proč kontejneru nepopisovat konkrétní závislosti (například aktuální uživatel závisí na konkrétním připojení a nemůže se použít to druhé, které slouží k jiným věcem)? Jak toto autowiring řeší a jak to funguje přímo v Nette?

S autowiringem se zatím taky moc nekamarádím. Právě proto, že když máš dvě služby se stejným rozhraním, tak framework háže výjimku. Ale u těch tříd, které se nemají autowirovat se to dá vypnout. Souhlasím, že za tím cítím magii (že je něco deterministické neznamená, že to není magické). Na druhou stranu nehodlám proti autowiringu zbrojit dokud se s ním alespoň nenaučím pracovat. Navíc to není žádný Davidův zlepšovák, ale běžně používaný princip při práci s DIC.

A ne, nemáš jít cestou že si přepíšeš půl frameworku. To jsme dělali jednou v práci a mě se výsledek rozhodně nelíbil. Přepisuješ jen chování, které potřebuješ z nějakého dobrého důvodu změnit (u mě to je TemplateLocator a jeho napojení na presentery i komponenty namísto samostatných metod pro hledání šablon, dále pak BaseForm, který umí renderovat pomocí FileTemplate). Většinou se jedná o rozšíření funkcionality podle mých potřeb. S programováním v Nette začni od Sandboxu a nebudeš mít problém.

Jestli se ti nelíbí povinná sekce development, tak napiš na fórum a třeba nás bude víc a povinnost sekce se zruší. Zrovna tohle mi přijde magické, víc by se mi líbilo, kdybych si mohl režimy vytvářet sám a laděnku zapínal samostatně, třeba přímo v configu té které sekce.