univerzális website mag
Sziasztok, egy eléggé érdekes és bonyolult kérdésem van...
Arról van szó, hogy készítettem egy olyan tulajdonképpen alkalmazás magot, a legalapvetőbb osztályokkal, aminek a segítségével egy weblaphoz tartozó elemi műveleteket meg tudok valósítani, és ehhez csak be kell másolni a könyvtárszerkezetet az új projekthez, és amennyiben el vannak készítve a nézetek, már van is bejelentkezés, automatikusan azonosítja a felhasználó csoportját a cucc, minden megtekintéskor, és ebből adódóan van benne alapból jogkezelés is.
Ez eddig mind szép és jó, működik is gyönyörűen. A probléma ott kezdődik, hogy ügye általában egy portálhoz mindenképpen tartozik egy adminisztrátori felület is, ami gyakran egy másik alkalmazás ami ugyan azon az adatbázison dolgozik mint amelyen maga a portál vagy weblap is. Itt kezdődnek a bajok, méghozzá először adatbázis szinten. Tartozik ehhez a "maghoz" egy jól szituált DB szerkezet is, és az objektumok ezen a táblaszerkezeten végzik az ő kis munkájukat. Na de ha ehhez hozzákapcsolok egy admin felületet, akkor annak is kell ugyanaz a mag, és ugyanez a táblaszerkezet. Ez azért jelent problémát, mert ügye az adminisztrációs felületen más jogosultságok oszthatók ki mint magán a weboldalon, és nem akarom keverni őket. ellenben azt sem szeretném, hogy más nevet adok az admin felülethez tartozó tábláknak, pl.: admin_priv stb.. , hiszen akkor az azt jelenti, hogy a programozásba is át kellene írni a lekérdezéseket.
Az tűnhet még jó megoldásnak, hogy az adminisztrációs felületet mivel külön alkalmazás, ezért külön adatbázisban tárolom a hozzá tartozó táblaszerkezetet, de ez meg azért nem jó, mert sokan minimális tárhelyet regisztrálnak, és sok helyütt csupán egy darab adatbázis jár ezekhez a tárhelyekhez.
Szóval erre a kis problémára várom a javaslatokat, gyakorlatilag bármilyen megoldás érdekel, ha valakinek nem tiszta, nagyon szivesen megosztom akár a forrás egészét akár az adatbázis szerkezetet is veletek. :)
Előre is köszi a helpet!
■ Arról van szó, hogy készítettem egy olyan tulajdonképpen alkalmazás magot, a legalapvetőbb osztályokkal, aminek a segítségével egy weblaphoz tartozó elemi műveleteket meg tudok valósítani, és ehhez csak be kell másolni a könyvtárszerkezetet az új projekthez, és amennyiben el vannak készítve a nézetek, már van is bejelentkezés, automatikusan azonosítja a felhasználó csoportját a cucc, minden megtekintéskor, és ebből adódóan van benne alapból jogkezelés is.
Ez eddig mind szép és jó, működik is gyönyörűen. A probléma ott kezdődik, hogy ügye általában egy portálhoz mindenképpen tartozik egy adminisztrátori felület is, ami gyakran egy másik alkalmazás ami ugyan azon az adatbázison dolgozik mint amelyen maga a portál vagy weblap is. Itt kezdődnek a bajok, méghozzá először adatbázis szinten. Tartozik ehhez a "maghoz" egy jól szituált DB szerkezet is, és az objektumok ezen a táblaszerkezeten végzik az ő kis munkájukat. Na de ha ehhez hozzákapcsolok egy admin felületet, akkor annak is kell ugyanaz a mag, és ugyanez a táblaszerkezet. Ez azért jelent problémát, mert ügye az adminisztrációs felületen más jogosultságok oszthatók ki mint magán a weboldalon, és nem akarom keverni őket. ellenben azt sem szeretném, hogy más nevet adok az admin felülethez tartozó tábláknak, pl.: admin_priv stb.. , hiszen akkor az azt jelenti, hogy a programozásba is át kellene írni a lekérdezéseket.
Az tűnhet még jó megoldásnak, hogy az adminisztrációs felületet mivel külön alkalmazás, ezért külön adatbázisban tárolom a hozzá tartozó táblaszerkezetet, de ez meg azért nem jó, mert sokan minimális tárhelyet regisztrálnak, és sok helyütt csupán egy darab adatbázis jár ezekhez a tárhelyekhez.
Szóval erre a kis problémára várom a javaslatokat, gyakorlatilag bármilyen megoldás érdekel, ha valakinek nem tiszta, nagyon szivesen megosztom akár a forrás egészét akár az adatbázis szerkezetet is veletek. :)
Előre is köszi a helpet!
hejj
én mindenképpen lenyomnám a torkukon, hogy legyen két adatbázis..
de nem ez volt a kérdés.. drupalt néztem mostanság nagyon felületesen, mindesetre ott úgy van (lehet, hogy rosszul vettem észre), hogy nem válik külön az admin és frontend látványosan..
lényeg a lényeg oldd meg, hogy az admin felület a frontended része legyen.. frontenden veszel fel adminhoz tartozó csoportokat (mert csoportokat csak kezel a 'mag'-od) és ha még oldalanként külön template-et is kezel a rendszered, akkor akár úgy is nézhet ki, hogy a két rendszer külön van.
valami ilyesmit tudok elképzelni, remélem sikerült megértenem a problémád, és segíteni is tudtam..
hmm
Az admint pedig azért akarom különválasztani, mert csináltam sok olyan megrendelést már, aminél a frontenden a felhasználók tulajdonképpen szinte semilyen interakciót nem tudnak végezni, nincsen sem bejelentkezés sem egyéb, ellenben a tartalmat ami megjelenik erősen adminisztrálni kell. Egy forumnál egyértelműen egy alkalmazásként kezelem én is, de pl egy hírportál esetében ez annyira nem nyilvánvaló.
Egyébként csoportokat kezel igen, és a csoportok, illetve a felhasználók is azonos táblából származnak az admin felület illetve a frontend esetében is. Tehát ha valaki adminként van benne a DB ben akkor az autómatikusan be tud jelentkezni a weblapra is, feltéve hogy va ilyen szolgáltatás, de általában a weblap őt is hagyományos userként kezeli, persze kivétel a blog, és hasonló alkalmazások. Egyébként külön oldalakénti templatekkel valositom meg az egyes nézetek, tehát ez a kritérium is adott.
Igazából a problémám nekem azzal van, hogy más és más nézetek illetve események tartoznak az admin illetve a nem admin felülethez, és ezeket mindenképpen szeretném külön választani. Ekkor tehát szükségem volna egy olyan táblára amiben az adminhoz tárolom a nézeteket és az eseményeket, és amiben a portálhoz. És ehhez szeretnék egy általános osztályt irni, ami mindkettőt képes lekezelni, azt is ha az admin jogait szeretném vizsgálni, és azt is, ha a hagyományos userekét. :)
Valószinüleg az lesz a megoldás, hogy kiegészitem a privilégiumkezelő osztályomat és bevezetek egy flaget a konfigurációs fileban, amivel kapcsolgatom, hogy ez az alkalmazás éppen admin, vagy nem admin, és ehhez mérten a Priv osztály jogvizsgáló metódusa majd jól eldönti magának, hogy melyik táblában kell keresgélnie :)