Rozdělení aplikace do více "instancí", ale jenom jedny zdroje rubrika: Programování: PHP

2 zapotocnylubos
položil/-a 20.6.2017

Ahoj,

hned mě opravte jestli je moje myšlenka úplně mimo, ale mám projekt, kde si můžete požádat o vytvoření vlastní instance aplikace na subdoméně.
sub1.domena.cz - Customized(barvy, loga,...) Nette aplikace
sub2.domena.cz - Customized(barvy, loga,...) Nette aplikace

a moje myšlenka byla, jestli neni možné toto sloučit, aby tam nebylo x krát /vendor,... aby ty zdrojové kódy byly jednotné - při upgradu se aktualizují všechny subdomény.

Jde pomocí nette managovat subdomény tímto stylem?
nějak číst "parametr" - subdoménu, z toho s načíst nějaké configy nebo tak nějak?

Zase na druhé stránce, je potřeba zvážit, jestli půjde udělat separátní přihlašování uživatelé na těchto subdoménách.

Co myslíte, jak se to má řešit?

Díky moc
Luboš

Komentáře

  • rmaslo : Rozhodnutí může ovlivnit i otázka certifikátů. Třeba pokud to má jet na https a z nějakého důvodu by třeba nebyly vhodné wildcard, tak by se to mohlo docela zkomplikovat. 21.6.2017
odkaz
2 Vaclav Jurecek
odpověděl/-a 30.6.2017

My tohle delame uplne bezne. V nette aplikaci. Treba web lomax cz a vsechny partnerske weby jednotlivych prodejcu po cele cr, kterych je asi 80 pohani jeden kod. Kazdy ma vlastni domu ci subdomenu, vse je smerovano na jeden vhost na hostingu. A kazdy muze mit specificke chovani, nebo pouzivat to vychozi.

Protoze veskery kod je injektovan pres di, je snadne vytvorit mnoho odlisneho chovani pro kazdeho partnera bez nutnosti ifovani v kodu. Udrzitelnost je uzasne snadne.

Jako prvni mas sluzbu domainResolver, ktera bere request. Z nej zjistis domenu ze ktere pozadavek prisel a overi zda je domena mezi platnyma. Kdyz jo stava se tato sluzba kontextem pro tovarny na ostatni sluzby. Vse ostatni co potrebujes aby se chovalo v zavislosti na domene mas v dalsich sluzbach a componemtach. Ty sluzby ti vytvari tovarna ktera svou instance method cleni na zaklade kontextu ziskaneho viz vyse. Pak ti staci v te factory mit jeste zavislost na di container a z nej vytahnes hotove sluzby podle predem dane jmene konvence.

Priklad mas sluzbu UserServise v containeru pojmenovanou user, a SubdomainUserServise v containeru pojmenovanou sub1User. Udelas si tovarnu na userServise ktera veme ten domainResolver, zjisti z nej prefix aktualni domeny, napr sub1, slozis si nazev sluzby sub1User a z containeru zjistis zda dana sluzba existuje, kdyz jo vratis kdyz ne vratis vychozi implementaci tedy sluzbu bez prefixu, tedy user. Vsechny user sluzby implementuj pochopitelne stejny interface a muzou a nemusi mezi sebou dedit. KdZ tohle delas casto, vyplati se tu kontextove zavislou tovarnu napsat tak, aby pouzit pro kazdou sluzbu znamenalo jen definici te jmene konvence. Vse ostatni pak zustava.

Takto muzes mit i tovarnu ktera vraci jine tovarny, treba tovarnu na tovarny component. Muzes takhle resit vse i router, takze muzes mit na subdomenach jine routy. Muzes takhle hodne kouzlit. Na tom Lomaxu jsme takhle resime i treba kombinaci vlastni domeny a jazykove mutace.

Vse je to o tom si stanovit tu jmenou konvenci sluzeb, a vse dekomponovat do sluzeb a neprasit to v prezentru.

Pro zobrazení všech 7 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.