Podmíněné načtení konfigurace podle URL

akadlec

Tak jsem se dostal k řešení problému jak extendovat neona podle toho jakou mam url. O co konkrétně jde? V aplikaci mam url ve tvaru: www.apliace.tld/ALIAS/cs/… a to ALIAS právě definuje jaké se mají načíst moduly (resp. jsou k dispozici), jaká je konfigurace atd.

Před Nette jsem to řešil tak že sem se koukl na url, zkusil vyhledat první blok a ten pak hledal v DB, když se našel záznam podle aliasu tak se pokračovalo dál jinak se dropnul error. Info o tom záznamu jsem pak měl k dispozici kdekoliv v modulech, takže nebyl problém udělat select s podmínkou na daný ALIAS.

Jak tedy na to v nette? Zatím jsem to vyřešil tak že ve startupu basepresenteru provedu načteni z informaci co mam z routeru (tam sem si tu url zadefinoval). Potud to je ok. Ale potřeboval bych to info o načtené konfiguraci předat i modelum, komponentam atd. Ideálka by bylo kdybych to dostal i do neonu abych mohl zadefinovat nějaké cesty které jsou právě závislé na tom aliasu.

Nakopne mě někdo správným směrem? ;)

Snad sem to pochopitelně sepsal ;)

enumag

Naprosto nechápu k čemu by to bylo dobré, připadá mi že vymýšlíš nesmyslné řešení na problém který se má řešit jinak.

akadlec

Jedna App, jedna DB, podle aliasu v url se rozhodne co bude aktivní a co ne. Pokud máš tip na jiné řešení sem s ním ;)

jinak já řešní mám ale v nonnette aplikaci a funguje bez problému, teď ho jen potřebuju dostat do nette aplikace.

Editoval akadlec (22. 2. 2013 12:20)

enumag

„co bude aktivní a co ne“ – jaký má smysl něco vypínat? Vždyť to ani není vypnutí když to z jihého aliasu stále přístupné bude. Tip na jiné řešení ti dám až pochopím problém (= důvod proč to děláš).

akadlec

Př. přihlásím se pod alias1 a budu mít k dispozici pouze modul1 a modul2 a veškerá práce bude vztažená jen k tomu alias1. Přihlásíme se pod alias2 a budu mít k dispozici jen modul2 a modul3. To co bylo přidáno v modul2 pod alias1 není k dispozici v modul2 pod alias2

enumag

Ten příklad je příliš abstraktní než abych z něj dokázal vydedukovat, co se vlastně snažíš vyřešit těmi „aliasy“.

Mohl bys to trochu více rozvést?

Editoval enumag (22. 2. 2013 12:47)

akadlec

tak ještě jednou ;) jeden zdroják a nad ním více stejných aplikací, tj abych nemusel vždy kopirovat celou složku app, ale zároveň dokázalo omezit k čemu má ten alias přístup (limitace modulu)

a nebo ještě jinak. Prostě modulární CMS, jen s tím že to co bude mít aktivní se určí tím aliasem.

Editoval akadlec (22. 2. 2013 12:49)

Filip Procházka

Řešíš oprávnění, nebo máš hrůzu z toho, že by se ti zapínaly služby, které request nevyužije?

V prvním případě je otázka hodně špatně položená. V druhém je to pouze paranoia. V Nette se nevytváří nic, pokud to skutečně nepoužiješ v konkrétním presenteru.

enumag

Pokud máš několik instancí podobné aplikace tak bych očekával že budou pracovat nad různými databázemi. Ty ale píšeš že pracují nad jednou což mne poněkud mate. Další věc co mi není jasná je že to máš vlastně vše pod jednou doménou – v reálu ty aplikace stejně poběží každá jinde, ne? Jde ti tedy jen o development režim několika aplikací s většinou společného kódu?

akadlec

Filip Procházka: ani jedno. Čistě jde jen o nastavení co je v dané instanci k dispozici a co není, podle toho se pak sestaví navigace, popřípadě nějaké další části stránky.

enumag: je úplně jedno zda má každá instance svou db, či sdílejí jednu s tím že tam je identifikátor oné instance. Ano vše je zastřešeno pod jednou doménou a to jaká instance se načte určí právě ten alias který je na začátku query: www.aplikace.tld/…ry-akce-atd/ a v reálu ty aplikace pobeží na jednom místě a jejich identifikace je právě pomocí toho aliasu.

hAssassin

nemohl bys uvest konkretni priklad? protoze ikdyz to tu ctu prubezne tapu stejne jako asi tapou ostatni a docela by me zajimalo co mas presne na mysli. a nebo jde jen o slovickareni a modul u tebe ma jiny vyznam nez modul v nette?

Ale sem zvedavej co z toho vzejde :D

akadlec

pánové vy mě dáváte ;) už nevím jak jinak to popsat ;)

Mějme pro příklad modul ArticlesModul a NewsModul. Oba tyto moduly jsou rozděleny na Front a Admin takže v adresářové struktůře to je pak nějak takto:

app
  conf
      -conf.neon
      -services.neon
  modules
      ArticlesModule
         FrontModule
         AdminModule
      NewsModule
         FrontModule
         AdminModule

a dále mějme url např: www.slozitaplikace.tld

v databázi je udělána tabulka kde jsou uloženy jednotlivé možné instance pro příklad dvě

id	name		alias
1	Začátečník	zac
2	Profík		prof

a uživatel kterému byl vytvořen účet do instance začátečník zadá url ve tvaru:

www.slozitaplikace.tld/zac/		pro front
www.slozitaplikace.tld/admin/zac/	pro admin

Aplikace podle aliasu (tedy zac) si načte z tabulky info o tom jaké moduly může daný uživatel využívat a zjistí že instance začátečník má jen novinky. Takže v adminu se uživateli zobrazí menu kde bude mít jen možnost vytvářet novinky. Taktéž na frontu se mu v menu vygeneruje jen a pouze odkaz na presentery modulu novinky a nic jiného. Prostě bude mu dovoleno pracovat s moduly které má daná instance povolené.

V základu by se to dalo přirovnat třeba k přístupovým právům kde se daným uživatelů omezí přístup do nějakých částí webu

Ale tady je to ještě rozšířeno o vlastní konfiguraci těch modulu, tj. v každé instanci lze nadefinovat např kolik novinek se zobrazí na stránce. Např v instanci začátečník je to jen 5 a v pokročilém je to 20 atd.

Doufam že jsem nyní vnesl trochu světla ;)

A jak jsem psal výše v nonNette appce to řeším tak že ten alias vysosám z url při startu appky, podle něj pak vytáhnu info z db, info jaké moduly má aktivní, konfiguráky atd a to vše pak naperu do základního konfigu co je společný pro všechny instance.

Tady mě zatím napadá trochu krkolomné řešení a to pomocí separatních www adresářů kde každá instance bude mít svůj www adresář ve tvaru onoho aliasu a budu schopen to tam dotlačit ještě v boostrapu, resp dostanu tam ten alias ;) ale to bych už teoreticky dokazal překopat aby to bylo v neonech a né v db

MartinitCZ

Takže řešíš role a oprávnění, ale úplně špatným způsobem. ;) Toto se určitě nemá řešit na úrovni URL, ale na úrovni Identity.

Editoval martinit (22. 2. 2013 13:36)

akadlec

martinit: ne, jak jsem psal výše neřeším role a oprávnění ale jednotlivé instance aplikace. V mém řešení je db sdílená, ovšem v jiném řešení by db pro jednotlivé instance mohly být klidně oddělené.

duskohu

Neviem ci spravne chapem. Ty chces na zaklade parametru v url, dajme tomu nazveme userType zistit nejake udaje z datavaze? Nastavenia modulu, popripade ake muduli su pre uzivatela dostupne, a na zaklade dostupnich modulov vygenerovat menu odkazov na presenteri povolenich modulov?

Editoval duskohu (22. 2. 2013 13:42)

akadlec

duskohu: v podstatě ses trefil ale není to na usera ale na tu instanci protože pod danou instanci může být neomezeně userů a ti jsou pak zařazení do svých skupin.

hAssassin

Ano, resis opravneni a role uzivatelu! A resis to spatne! Mam ale jeste dotaz: jsem uzivatel zacatecnik a jsem prihlaseny na tvem webu a jsem na URL www.slozitaplikace.tld/zac/ coz mi zobrazi nejakou stranku treba s 5 novinkami. Co kdyz ale budu vych*any zacatecnik a zmenim URL na www.slozitaplikace.tld/profi/ pricemz budu porad prihlaseny pod svym zacatecnickym uctem?

akadlec

Ne neřeším. Pro zjednodušení mějmě dvě rozdílné databáze jednu pro ZAC a druhou pro PROFI. Pokud změníš url tak se invaliduje tvoje přihlášení tudíž se budeš muset znova přihlásit.

Jinak už fakt nevím jak jinak vám to popsat. Představte si klasické CMS, je jedno na jakém FW je založené, třeba joomla. Tam když nahrajete nějakou komponentu tak se do db přidají jak její tabulky tak se do centrální tabulky přidá informace že máte danou komponentu aktivní a můžete ji používat. Když ji z této tabulky odstraníte tak se vám zakáže i když jeji tabulky či soubory budou stále v dané instalaci joomly nainstalovány. A teď si představte že si takto vytvoříte joomlu se všemi moduly a komponentami co chcete kdy použít a jen pomocí nějaké parametru určovali jaká db se použije a tudíž co vše bude aktivní.

duskohu

Skus pouvazovat nad niecim takymto, lebo tvoje riesenie nie je uplne koser:

Mas moduli, kazdy modul ma svoj config.neon kde budu nastavenia tykajuce sa daneho modulu
urovis si jeden module.neon kde budes mat len nazvi modulov napr:

- Default
- Article

V bootstrap si urobis nacitavanie konfigurakov pre modul napr:

$adapter = new \Nette\Config\Adapters\NeonAdapter();
$modules = $adapter->load(__DIR__ . '/config/modules.neon');
foreach ($modules as $module) {
    $configFile = __DIR__ . '/' . $module . 'Module/config/config.neon';
    if (file_exists($configFile)) {
        $configurator->addConfig($configFile);
    }
}

odporucam: http://filip-prochazka.com/…e-frameworku

Urozis si usera ten ma nejaku rolu, rolu mozes chapat ako „skupinu“ napr: zaciatocnik, profik, user okrem toho moze mat aj viac roli, napr: admin, editor …, popripade ked mas userov v skupinach, tak nastavis potrebne role userom v danej skupine.
Userom pridelis role ake potrebuju tie mozes pridelovat aj na zaklade tej tvojej skupini zaciatocnik profik …
teraz maju uzivatelia role, a v aplikaci si nastavis ze tieto ktore role mozu robit co, a pri generovani menu budes zistovat ci user ma opravnenie na to aby mohol pouzit presenter, akciu …

a ak nie, tak proste tu polozku do menu nedas, a mas to osetrene aj tak ze keby maualne zadal url, tak ho tam proste nepusti, lebo nema rolu, to si nastavis v secure Presentru.

a posledna cast, ked uz sme role previazali so „skupinou“, a mas nejake data ktore potrebujes vytiahnut z db, tak to urob na zaklade nazvu role, alebo skupiny

Toto som len tak zrhuba napisal, takze bude treba riesit este nejake musky, popripade zmenit logiku, ale princip som tam zhrnul

EDIT: prepac @akadlec ale @hAssassin ma pravdu riesis role, len to kombinujes s dalsimi vecami a komplikujes to trosku.

Editoval duskohu (22. 2. 2013 14:05)

akadlec

jejda, asi sem neměl na začátku zmiňovat nějaká oprávnění a role protože jste se toho všichni chytli ;)
základní princip je ten mít na venek dvě samostatné instance ZAC a PROFI které nejsou mezi sebou nijak provázány, jediné co mají společné tak jsou vlastní presentery ale to je tak vše. Pokud vam to pomůže k představivosti mějme i klidně dvě url: zac.slozityweb.tld a profi.slozityweb.tld. obě tyto domény směřují do jednoho document rootu takže mají společný index.php, ten skočí na bootstrap, načte si neon a další věci okolo a spustí apku.

Nemám problém ve startupu si vytahnout informace o dané instanci co je právě spuštěna i v rámci presenteru si ji klidně předám, co ale řeším jak ji čistě ty informace o instanci dostat do všech částí (komponenty, moduly atd)

Pod informacemi instance si přestavte klidně objekt entity kde je ID, Name, Alias a další info vytažené z db

EDIT
a ještě doplnění k duskohu:
sice fajn vyřešení config.neon pro moduly ale já je potřebuju ještě rozdělit na konfig dané instance, tj instance PROFI bude mít jiný konfig modulu Články než instance ZAC

EDIT2
opravdu neřeším role. Články které byly přidány pod instancí ZAC nesmí být dostupné pod instancí PROFI, tj. oddělené prostředí a pro zjednodušení tedy články pro instanci ZAC jsou v jedné DB a články pro instanci PROFI jsou v druhé.

Editoval akadlec (22. 2. 2013 14:14)

Michalek

Všichni s tím mají nějaký problém přitom je to jednoduchý. Přesně chápu co děláš, protože to dělám taky.

<?php
- bootstrap.php, config.neon, config.domena1.cz.neon, config.domena2.cz.neon

$configurator->addConfig(__DIR__ . '/!config/config.neon', FALSE);

preg_match("/[^\.\/]+\.[^\.\/]+$/", $_SERVER['HTTP_HOST'], $matches);
$url = $matches[0]; // upravit jak potrebujes

$configProject = __DIR__ . '/!config/config.'.$url.'.neon';
if (is_file($configProject))
	$configurator->addConfig($configProject);
?>

Stačí takhle? ;)

Editoval Michalek (22. 2. 2013 14:54)

akadlec

Michalek: bingo, konečně někdo pochopil mou myšlenku ;) Jinak tato možnost mě taky napadla, jen sem doufal že to půjde v nette nějak „čistěji“ ;) možná to ale vyřeším přes subfoldery ve wwwDir, protože v mém řešení se počítá i vícero domén na jednu instanci a pak z dirname získám ten „alias“

hAssassin

no ok, sice porad moc nechapu pointu, ale asi vim jak to myslis. A proc to neudelat pres routing? Cili v route mit primo ten alias? V basepresenteru si pak nastavis ten alias jako persistent parametr a ten se ti naplni pri kazdym requestu. Cili pak uz v prezenterech, resp modelech muzes pouzivat tento alias pro pristup do DB. To jak se dostane do modelu/komponent/whatever je otazka na DI.

A nebo porad nechapu co potrebujes?

Michalek

Tak to moje řešení není samozřejmě závislý přímo na názvu domén, ale na tom, podle jakých podmínek se daný config.*.neon načte. Může se klidně načítat podle třetího písmenka ve druhém slově za pomlčkou.

Pro ostatní: Představte si dva stejné zpravodajské weby, jeden píše o myslivcích, druhý o rybářích. Databáze je stejná, lišit se má obsah, barvy, povolení komentářů pod články. Systém je ale jen jeden a podle domény se nastaví co to má umět a co ne, změní se automaticky CSS. Jednoduchý.

Editoval Michalek (22. 2. 2013 15:10)