Oldal 1. konfiguráció bevezetését blog
Ma zavedom beszélgetés egy ilyen látszólag egyszerű téma, mint a helyszínen konfigurációt. Azaz, beszéljünk a dolgokat, mint adatbázis-kapcsolat beállításait, a különböző beállításokat, ezeket a dolgokat, és hogyan tárolja az összes ezt a munkát.
Azt ossza ezt a beszédet három részből áll:
- A jelenlegi pillantást a különböző lehetőségek megszervezése a config. Ez a rész elsősorban összpontosít kezdőknek.
- A második gondolkozzanak bonyolultabb dolgokat. Például hogyan lehet támogatni egy sor különböző konfigurációk egy rendszer.
- És a harmadik rész megpróbálja faragni az egészet kódot.
Tehát, ha ez lehetséges, hogy tárolja a rendszer beállításait?
Sehol tárolni
Lehetőség van, hogy ne feszítse külön beállításokkal, tárolás, és használja őket közvetlenül a megfelelő helyen:
mysql_connect ( 'localhost', 'vasa', 'QWERTY');
És ez így kívánatos, hogy minden fájl, amelynek szüksége van az adatbázishoz való hozzáférés. Aztán megpróbálja módosítani bármely paraméter feltétlenül válik egy felejthetetlen nyaraláshoz.
Miután ezzel a megközelítéssel egy ideig a honlapok a mennyiség több mint három kép, a fejlesztők általában észre, hogy nem tudunk élni.
A globális változók
Az első dolog, amit teszel, miután kiderült, hogy a rendszer, akkor állapítsa meg egyszer és egy helyen:
Ez jobb, de vannak hátrányai. Ugyanaz, mint általában a globális változókat. Dirtied globális összefüggésben heterogén, strukturálatlan adatok. A körök lesz állandó probléma. És mivel az egész rendszer e config, nyilván fog alapulni globális változók, akkor van egy kérdés a konfliktus a nevek az összes kellemetlen következményekkel jár.
define ( 'DB_HOST', 'localhost'); define ( 'DB_USER', 'vasa'); //.
Most már dirtied világviszonylatban heterogén, strukturálatlan állandók. Az egyetlen öröm: rendelkezésre állnak minden hatáskörben, és nem lehet véletlen módosítását.
Egy kis előnyt a globális változók bizonyos esetekben még rosszabb, mint ők állandók.
adatbázis
Beállítások tárolhatók az adatbázisban (jó, kivéve, sőt, a beállítások az adatbázishoz csatlakozáshoz), és ha szükséges, válassza ki őket kéréseket.
Első pillantásra ez egy nagyon vicces, és joga van a létezését a döntést. Különösen azért, mert számos népszerű fórumok és blogok használja.
De a közelebbi vizsgálat, ez a legostobább dolog, amit gondol erről a témáról. Az adatbázis tárolja a beállításokat meg kell változtatni a webes felületen keresztül, valamint a felhasználói beállítások, stb Tartsa a teljes konfiguráció van piz.ts.
Ez a döntés általában feltételezik, rugalmas, mivel lehetővé teszi, hogy módosítsa a beállításokat valamilyen admin felületen, anélkül, hogy hozzáférjenek a kódot (vagy nem bonyolítja a hozzáférést ezekhez). Sőt, ez a kurva nem szükséges az általános beállításokat. Senki életemben nem kell változtatni a mappa elérési útját a témákat a fórum SMF. És ha szükséges: akkor is kell bemenni a kódot, és másolja a mappát egy új helyre.
Változás valami nincs bennük előírt admin területen, és még egy új paramétert fordítja a különböző kellemetlen érzéseket. A kísérlet, hogy másolja magát lokalku helyszínen a fejlesztés minden kiderül valami mazochista. Másolása után meg kell mászni a bázis, és próbálja felfedezni, ahol az összes paramétert kell változtatni. Különösen tetszett, hogy tárolják azokat általában teljesen emészthetetlen formában.
Most már mindent egyetlen tömb konfiguráció és nem szennyezi a globális környezetben.
Akkor is megszabadulni a rossz szokások és ne feledjük, hogy az asszociatív tömb lehetővé teszi számunkra, hogy strukturálja ami emberileg:
Most a szemet gyönyörködtető, és nem tud dolgozni az egész tömböt, és részei.
return array ()
Nem mindenki tudja, hogy tudja befejezni a fájl feldolgozása, valamint a funkciót a bevallását. Sőt, mivel lehetséges, hogy visszatérjen az érték, amely azt eredményezné tartalmaznak, vagy megkövetelik. Mi akasztott ezt a fájlt.
Hozzon létre egy konfigurációs fájl (config.php mondani.):
Most nincs globális változókat. Config nem határozza meg azt, hogy hogyan használja a kódot, és általában csak konfigurációt. És a kódot a megfelelő helyen:
$ Config = include ( '/ útvonal / / config.php'); // Read konfigurációs fájlból egy változó
$ Config = Config :: get (); // a megfelelő helyen
Ellentétben az előző példában, csökkentettük a kapcsolatot fájlt egyszer, még sok konfigurációs kérelmeket és megszabadulni az alkalmazás kód ismeretében a fájl elérési útját.
De ennél sokkal fontosabb, hogy a megosztott tárolási konfiguráció és egy felületet elérni. Kód olvasás konfiguráció nem teher maga ismereteket, hol van, hogy milyen módon és milyen módon (összetett lehet) keletkezik. Akkor teljesen megváltoztatja a tárolás - az alkalmazás kód nem fogja érinteni.
Ettől a pillanattól kezdve a tárolása config megteheti gondolkodás nélkül a kérdéseket, és fordítva.
javított felület
Interfész config (az előző példában a Config :: get ()) lehet javítani a végtelenségig, és a szeretet.
Vegye ki a statikus, hanem lógott a témában a magic methods és SPL-interfészt kap valamit, mint:
$ Db_host = $ konfigurációkkal> db-> host; $ DB_USER = $ konfigurációkkal> db-> felhasználó;
Megszerzése config-objektum lehet tenni keresztül NOB konténer, vagy valamilyen más homályos dolog.
Javítása tekintetében a felület lehet gondolni egy csomó dolgot, és még több is található az interneten kész. Hagyjuk ezt a témát a jövőben középpontjában kizárólag a konfigurációs tárolási módszer.
Tárolás formátumok: Adapter
Mint a gyakorlat azt mutatja, a leginkább kényelmes segítségével a kód formátum egy ábrázolása a konfigurációs fa struktúra. Azaz mindegy asszociatív tömb.
De tároló kényelmes lehet különböző formátumokban. Ismét egy tömböt (mint fent), az XML, ini-fájl, vagy valami más.
Mivel a tároló a reprezentációk már elválasztott, tudjuk tárolni, amit akarsz, anélkül, hogy ez a felület. Az egyetlen dolog, amire szükség van ahhoz, hogy a kiválasztott formátumban tárolja egy fa struktúra elérni (azaz, más adaptert indítható).
Az egyik ilyen megközelítés: Zend_Config.
Ui Mi kerül egy konfigurációs fájl
Végén a bevezető rész, hogy az tükrözze minden kell tárolni a helyszínen konfiguráció és mit nem.
Itt ilyen ide nem tenni:
$ Dir_root = '/www/site.ru/htdocs'; $ Dir_image = '/www/site.ru/htdocs/image'; $ Dir_thumbs = '/www/site.ru/htdocs/image/thumbs'; $ Dir_css = '/www/site.ru/htdocs/css'; // és egy tucat módon
Meg kell változtatni valamit, hogy menjen egy másik szerverre, másolt lokalku: erről akkor le kell ölni.
Azok az értékek, generálható alapján bázis, akkor jobb, ha létrehoz:
$ Dir_root = '/www/site.ru/htdocs'; $ Dir_image = $ dir_root '/ image' .; // vagy sablon típusát „> / kép”, amelynek kiszámítása a megfelelő helyen. $ Dir_thumbs = $ dir_image '/ hüvelykujj' .; $ Dir_css = $ dir_root '/ css' .;
Az alap értéke a példában a legtöbb esetben nyerhető automatikusan a $ _SERVER [ „DOCUMENT_ROOT”] vagy dirname (__ FILE__).
Ne próbálja meg beállítani minden részletét: extra munkát, te és azok, akik utánad jönnek, hogy a garantált és extra rugalmasság hasznos, nem mindig.
Kezdjük azzal, hogy talán elég. A következő rész fog beszélni sokkal érdekesebb dolgokat.
A python mindent szórakoztatóbb, például, hogy settings.py:
Database_name = 'név'
DATABASE_USERNAME = 'felhasználónév'
DATABASE_USERNAME = 'jelszó'
yuzaem és szükség szerint:
importálási beállítások
vagy
A Beállítások importálása database_name, DATABASE_USERNAME
stb
Van egy módja annak, hogy tárolja konfigurációs fájlok sokkal inkább :)
Nem látok sok különbséget, hogy őszinte legyek.
A következő cikkben fogok írni a dolgokat egy kicsit bonyolultabb, mondja, hogy ez a python csinálni.
Úgy értem, hogy nem kell semmilyen zendkonfigov és egyéb footy ... És ez nem (szuper) globális változókat, stb
Köszönöm, örömmel. A legtöbb esetben, és én, talán én vagyok a jó úton :).
phpdude, amely nyomva? Neighing?
artoodetoo, én benned, és nem kétséges :)
vajon hogyan kell tárolni a beállításokat a teljes telek és revraytit egyes aldomain, mint a ...?
A francba, Vasya_ts jelszó «qwerty» - ez csak tryndets, a telek megtöri az egy-kettő-három. Megváltozott valami pályán!
> Nem tudja, hogyan kell tárolni a beállításokat az egész oldal és revraytit egyes aldomain, mint a ...?
Nem értettem
> Nem értettem
Nos juzverej jön egy aldomain, és vannak funkcionális másik adatbázis lefagy ...
kostyl, a következő rövid cikket Chet.
vasa_c,
Azt javasoljuk, hogy használja méret return array (...);
majd írja: „Minden az értékeket, amelyek alapján generált egy bázis, és minél jobb”
Kérdezzen hogyan lehet kombinálni a fent leírt?
A következő példa konfigurációs fájlt:
$ CONFIG = array (
'A' => «1»,
'B' => «2»,
'Ab' => $ CONFIG [ 'a']. $ CONFIG [ 'b'],
);
2. Abban az esetben, az utak, általában kap körül épült __DIR__.
vasa_c, kösz az ötletet! A mostani feladat használni poluhakom.
Azt is gyakran használják poluhakami, az előny, hogy visszatérjen a munka elvégezhető ...
Jó іdeya, vіdmovivsya od meghatározni!