Přístup ke službě z bootstrap.php

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
michalbuk
Člen | 8
+
0
-

Dobrý den,

v config.neon jsem si vytvořil novou službu – structureLoader reprezentovanou příslušným objektem, která přijímá jako argument databázové připojení. Tuhle službu bych chtěl použít v souboru bootstrap.php k dynamickému načítání struktury webu z databáze, ale jak a jestli vůbec je přístupný ukazatel na tuto službu.

Děkuji

voda
Člen | 561
+
0
-

Takhle?

$configurator->getContainer()->getService('structureLoader');
michalbuk
Člen | 8
+
0
-

Přesně to jsem potřeboval. Díky moc.

Filip Procházka
Moderator | 4668
+
0
-
  • v config.neon jsi si službu nevytvořil, ale registroval.
  • služba přijímá připojení? Budu předpokládat, že se ti to nepovedlo docílit a uvedu příklad:
database:
	username: root
	password: foo
	driver: mysql

services:
	connection:
		class: DibiConnection
		arguments: ['%database%']

	structureLoader:
		class: StructureLoader
		arguments: [@connection]

Timto bychom měli vyřešenou službu.

  • Struktury webu? Co tím myslíš? Myslíš tím nějaký jeho obsah jednotlivých adres? Nebo presentery?

Když budeme uvažovat aktuální sandbox z githubu, doplníme pár řádku před $application->run()

$application->onStartup[] = function () use ($container) {
	// spustí se chvilku po zavolání $application->run()
	$container->structureLoader->load();
};

Každopádně bych doporučoval app/bootstrap.php moc nezaneřáďovat.

michalbuk
Člen | 8
+
0
-

Připojení (přes NotORM) mi funguje:

	services:
		dbConnection:
			factory: Storm\ModelLoader::databaseConnect
		structureLoader:
			class: Storm\StructureLoader
			arguments: [@dbConnection]

Abych nemusel do bootstrap rozepisovat jednotlivé routy, tak to řeším pomocí této služby. V databázi ukládám strukturu, každý záznam nese informaci o modulu, presenteru a view a zároveň titulek, keywords a description. Používal jsem to tak ve svém vlastním frameworku, tak se to snažím zapracovat do Nette.

Editoval michalbuk (29. 7. 2011 12:36)

Filip Procházka
Moderator | 4668
+
0
-

A nebylo by lepší, implementovat vlastní Nette\Application\IRouter ? tomu by jsi jen předat připojení k databázi, on by přijal http požadavek a vracel pak Nette\Application\Request, jako to dělají ostatní routery.

Nemusel by jsi nic hackovat, ani nastavovat. Takto by to bylo mnohem čistější a systémovější.

A taky bych si dovolil trochu polemizovat s tvým přístupem. Pokud nepíšeš vlastní CMS, důrazně doporučuji využít routování Nette a strukturu adres ovlivňovat maskami rout a názvy presenterů.

Editoval HosipLan (29. 7. 2011 13:11)

michalbuk
Člen | 8
+
0
-

HosipLan napsal(a):

A taky bych si dovolil trochu polemizovat s tvým přístupem. Pokud nepíšeš vlastní CMS, důrazně doporučuji využít routování Nette a strukturu adres ovlivňovat maskami rout a názvy presenterů.

Ano, píšu vlastní CMS, respektive ten co už mám přepisuju do Nette. Do routování Nette prakticky nesahám, jediný rozdíl je že ty routy načítám dynamicky a navazuju na ně relevantní proměnné jak jsem říkal – především titulek stránky a metainformace. Ten structureLoader jen načte routy, o zpracování http požadavku se postará klasický Router. Díky za postřeh, implementovat vlastní IRouter mě napadlo, ale teď se s tím učím a tohle řešení mi v tuto chvíli vyhovuje.

Tharos
Člen | 1030
+
0
-

Že do toho vstoupím, ze svých zkušeností nedoporučuji u CMS naimplementování nějakého všemocného databázového routeru či „SEO routeru“, který routuje všechny stránky. Mám lepší zkušenosti s přístupem, kdy se v podstatě využívá jen v Nette dostupné třídy Route a dopisuje se jen nějaký konfigurátor, který na základě struktury webu v databázi vygeneruje správně nastavené instance Route. Routy pak mohou vypadat úplně shodně, jako kdyby byly „napsány ručně“, jsou přehledné a při doplnění nějaké cache je toto řešení i výkonné.

norbe
Backer | 405
+
0
-

Tharos: Tohle by mne docela zajímalo proč to nedoporučuješ?

Tharos
Člen | 1030
+
0
-

norbe: Mám k tomu dva takové hlavní důvody, ale oba obsáhlé na vysvětlení a teď mi tu zrovna projektmanažer dýchá na záda. :) Dodám to sem ASAP.

Tharos
Člen | 1030
+
0
-

Ahoj, tak tedy ty mé dva hlavní důvody. Upozorňuji, že můj názor je subjektivní a reflektuje především mé zkušenosti (které mohou být docela odlišné od zkušeností jiných), takže prosím brát s rezervou. :)

  1. Řešení založené na třídě Route je obecně lépe pochopitelné

CMSko nad Nette, které ve firmě používáme, spěje teď v létě v podstatě do třetí verze. První dvě verze obsahovaly právě „všemocný databázový router“, který víceméně obsluhoval všechny požadavky (kromě adminu a pár dalších výjimek) a nutno podotknout, že docela hezky a svižně. Ve druhé verzi uměl i pěkně pracovat s dynamickými „dovětky“ URL adres, zkrátka dalo se toho s ním vykouzlit mnoho. Jenomže kdokoliv vyjma mě, kdo k tomu routeru přišel, v podstatě musel být formou mikroškolení seznámen s tím, jak to všechno funguje. Routing debuger, jenž obsahoval v podstatě jednu routu (kromě zmíněného adminu a podobně) a u které při každém standardním požadavku svítilo zelené „matched → yes“, k pochopení příliš nepřispíval.

A díky té dynamičnosti „dovětků“ URL kód toho routeru nebyl vůbec krátký a triviální. Dovolím si takovou malou odbočku: podívejte se třeba na HosipLanův popis jeho routeru (je to hodně historická věc, dost možná má dneska ve svém systému routování vyřešené úplně jinak). Dokážete si představit tohle naimplementované? A dokážete si představit, že k takovému kódu přijdete a budete mít za úkol to routování nějak upravit a bez pomoci pochopit, jak funguje? Například po HosipLanovo odchodu do Facebooku, totiž až už nebude možné absolvovat školení od autora? Zajisté to bude objemný kód a jeho myšlenky budou docela cizí jakémukoliv BNU (Běžnému Nette Uživateli).

Po podobných zkušenostech mě napadlo, že dynamické řešení spočívající ve výrobě předkonfigurovaných instancí Route tak, jak by je programátor přirozeně nadefinoval i bez použití nějakého CMS u pevně dané struktury webu, by mohlo mít něco do sebe. Implementace ukázala, že je to pro nezasvěcené skutečně mnohem lépe pochopitelné (což mělo pro mě osobně docela velký význam). Celkově je to řešení tak nějak více zaintegrované do Nette.

  1. Vestavěná třída Nette má vynkající vyjadřovací schopnosti, které není jednoduché napodobit

A je škoda se jich v CMSku zříci. Vestavěná třída Route umí aplikovat na jednotlivé parametry vstupní masku (dokonce i formou regulárních výrazů), umí komplexně vyjádřit povinnost a nepovinnost parametrů, defaultní hodnoty, umí nadefinovat vstupní a výstupní filtry, umí pracovat s foo parametry a dalo by se pokračovat. Ani druhá verze toho mého databázového routeru, ve které jsem některé z těchto věcí nasimuloval, nesahala možnostem Route ani po kotníky.

Zatímco mé současné řešení využívající právě třídy Route umí využít všech jejích možností a dají se tak v tom CMSku velmi pohodlně a přehledně routovat i skutečně složitá URL včetně vícejazyčnosti a podobných výmyslů.


Toliko mé důvody a velmi se těším na oponenturu. To těšení myslím vážně, protože mě rozhodně velice zajímají zkušenosti jiných. Obzvláště pak lidí, co píšou nad Nette CMSka (což je tipuji každý druhý zde na fóru :D).

Editoval Tharos (31. 7. 2011 23:01)

Filip Procházka
Moderator | 4668
+
0
-

Nemůžu říct, že bych na tom dělal celé dny, a už vůbec ne, že každý den. Ale průběžně vymýšlím „ultimátní“ řešení (průběžně = jednou za měsíc se hecnu, dám tomu dva dny a pak se na to vykašlu). Můžu jen potvrdit, že napodobit schopnosti routování Nette je nadlidský úkol.

Já mám hlavně problém vymyslet ideální filosofii ukládání jednotlivých stránek v CMS. Čili jakou zvolit strukturu. Vím jak to má vypadat, ale nelíbí se mi žádné mé řešení :) Pokud můžeš, docela bych ocenil kdyby jsi se na tohle téma aspoň teoreticky rozpovídal (ideálně v jiném vlákně, protože OT :D), ať už aby jsme se, my ostatní, inspirovali, nebo vyloučili další nedokonalé řešení :) Každá myšlenka tohle totiž posouvá dále :)

Co se týče „bez pomoci upravit“. Pokud na to budou testy, nemůže to být velký problém :)

Jo a, na ExtendableRouter se můžeš podívat, fungoval, skoro podle očekávání :) Ale ještě tam pár věcí chybělo. Každopádně jsem se na to vykašlal, když jsem zjistil, že generovat s ním URL prakticky není možné :) Jediné řešení, kdy má takový router význam, je, když máš pouze jeden FrontPresenter ;)

PS: každopádně, moc pěkný OT :)

Editoval HosipLan (30. 7. 2011 10:56)

Tharos
Člen | 1030
+
0
-

Ahoj, no, já bych to publikoval na jednu stranu rád, ale mám pár „ale“. Předně aby to dávalo smysl, musel bych to dát ven opravdu celé (není to jen věc rout, ale právě i způsobu, jakým se ukládají stránky), no a to by mohl být trochu problém, protože s firmou, která vývoj sponzoruje, mám uzavřenou jistou smlouvu o nevyvážení „know-how“. Ale minimálně jádro bych časem chtěl uvolnit, jenom ale sám si chci ještě některé věci rozmyslet a nechat uzrát.

Editoval Tharos (1. 8. 2011 22:45)