Diskuze: Rozdělení aplikace do více "instancí", ale jenom jedny zdroje
Člen
Zobrazeno 11 zpráv z 11.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
Dá se to udělat. Prostě všechny subdomény nasměruješ na ten samý index.php v jedné aplikaci, kde si potom pomocí routování vytáhneš subdoménu jako parametr url a dál zpracuješ v aplikaci.
a nebude to pak zlobit v případě, že se uživatel bude chtít registrovat na dvě subdomény nezávislé na sobě? nebude tam nějak zlobit session?
pozn.: určitě nedělej něco jako že by každá render/action/handle
metoda presenteru brala parametr subdomain
, místo toho si třeba
přepiš metodu startup()
, kde pomocí
$this->getParameter('subdomain')
získáš parametr
pohodlněji.
To by mohlo. Budeš si muset kontrolovat, kam ukládáš jaká data, ale snad
všechno v Nette naštěstí umí namespaces. Takže třeba cache, sessions a
pod. budeš všechno ukládat třeba do namespace subdom_$subdomain
a vše by mělo běžet v pohodě Možná se ještě budeš muset pohrabat v konfiguraci Latte enginu,
aby se ti šablony cachovaly zvlášť. Ale pořád je to mnohem snazší a
lepší než několik (skoro) identických instancí.
a když už by se něco takovéhle povedlo, jak to mám řešit s databází? mám mít jednu, s předponami třeba podle subdomén, nebo více databází? PS. chtěl bych použít doctrine. PS. Nevím jak v configu řešit podmíněné připojení k db.
jo a jak ses zmínit o těch namespace, můžeš mě nasměrovat alespoň,
kde bych tyhle věci mohl najít?
Díky
Nette dokumentace? Cache to bere jako druhý argument konstruktoru, session
jako jediný.
https://doc.nette.org/cs/2.4/caching#…
https://doc.nette.org/cs/2.4/sessions#…
S doctrine nemám zkušenosti, ale z toho co to je usuzuji, že to není
problém používat. Já bych asi šel do jedné databáze, kde prostě budeš
mít sloupečky s id subdomény a indexem. Mimo to tě asi jen málo hostingů
nechá vytvořit libovolný počet DB.
Pokud bys chtěl skladovat velké objemy dat, budou možná oddělené databáze
lepší=rychlejší.
Hlavní princip tady je, že se chceš vyhnout duplicitě- je mnohem snazší
udržovat jeden větší projekt, který se sám umí třídit a upravovat (a je
náročnější na naprogramování), než víc prakticky identických věcí
(ze strany programátora, ne klienta, pro kterého je změna barvy úplně jiný
web ). Tuhle praktiku se
nevyplatí používat v případě, že to výkonově nezvládá. Ale to to
potom můžeš rovnou nechat běžet na vícero serverech a to je úplně jiný
příběh.
Představ si, že musíš u každé instance provést migraci DB. Ručně, protože třeba nemůžeš ke všem DB z jednoho rozhraní a do každé se musíš přihlásit zvlášť - tam nalezneš odpověď.
a je lepší přidávat id subdomény do tabulek jak popisuješ, nebo dělat nové tabulky s prefixy?
Já bych všechno centralizoval. Vždyť přeci nechceš mít víc tabulek s
identickou strukturou... Ale jak říkám, záleží, co na tom chceš
uchovávat za data. Pokud budeš chtít mít v tabulce třeba jen nastavení
barviček, obrázků a pod. pro jednotlivé instance, nebude to problém mít v
jedné tabulce, protože těch dat bude prostě málo.
Pokud bys chtěl ukládat třeba každý přístup na každou instanci, bude to
strašně moc dat a asi by stálo za to používat tabulky s prefixem.
Mohlo by pomoct, kdybys uvedl, co to vlastně má dělat
Zobrazeno 11 zpráv z 11.