ugrás a tartalomhoz

Php konfig fájlok

inf · 2009. Szep. 17. (Cs), 02.40
Sziasztok!

Azon agyalok éppen, hogy a gyakorlatban mi haszna van a konfig fájloknak.
Konkrétan példának az adatbázis eléréseket vettem.

Ha mondjuk csinálok egy alap osztályt, ami képes lekérni az adatbázisból:

class DataAccess
{
	protected $dsn;
	protected $password;
	.
	.
	.
	protected function query($sql)
	{
		...
	}
}

aztán azt kiterjesztem,

class MyDataAccess extends DataAccess
{
	protected $dsn='mysql://root@localhost/mydata';
	protected $password='Test789Xyz';
	
	public function getSomeInfo()
	{
		return $this->query('...');
	}
	.
	.
	.
}
akkor szerintem teljesen felesleges kigyűjteni külön fájlba az accountot, ami az adott osztályhoz tartozik.
Ha meg mondjuk több osztály van azonos beállításokkal, akkor azokat egy azonos osztályból kell származtatni, és ennyi. Szerintem egy nagyon picivel lesz csak bonyolultabb így megtalálni a jelszavakat.

Ti mit mondtok?
 
1

Config file

janoszen · 2009. Szep. 17. (Cs), 08.06
Újrahasznosíthatóság a kulcsszó. Javítasz egy bugot az osztályodban, majd mind a 60 projektedet elkezded diffelni? Plusz, szabadságon vagy, költöz tetni kell a projektet, ki fog arra a 17 osztályra név szerint emlékezni, amiben át kell írni a paramétereket?
5

Config osztály

inf · 2009. Szep. 29. (K), 22.34
Hmm így viszont kell egy Config osztály, ami szétosztja a fájlban tárolt adatokat a "17 osztály" között. Végülis megoldható, csak át kell gondolni, hogy hogyan állok neki.

Javítasz egy bugot az osztályodban, majd mind a 60 projektedet elkezded diffelni?

Hát ez már más kérdés.. Az osztályaim általában úgy használom fel, hogy a szülőben nem adom meg az elérési utat, hanem csak a "végső" gyerekekben, szóval a final class-ekben. Tehát ha valami alapvető hiba van, akkor a kiterjesztett (szülő) osztályt nyugodtan átírhatom anélkül, hogy a gyereken módosítani kellene (persze csak akkor, ha a felület, amin kommunikálnak állandó marad).
2

eroforras

carstepPCE · 2009. Szep. 17. (Cs), 10.59
hat a konfig fajlok legnagyobb hatranya, hogy be kell olvasni oket, ami persze tovabbi eroforrasokat von el a rajta futo szamitogeptol. Hamar konfig fajlokat hasznalsz probald meg csak 1x beolvasni oket. Majd egy kozos helyrol, mondjuk a sessionbol hasznalni kesobb.

Mindez termesztesen csak abban az esetben hasznos, ha 3 vagy tobb configfajlt hasznalsz egy oldalhoz es sok felhasznalo hasznalja az oldalt 1xre

-cs-
Sanyi
6

???

inf · 2009. Szep. 29. (K), 22.37
Majd egy kozos helyrol, mondjuk a sessionbol hasznalni kesobb.

Ezt nem nagyon értem.
10

cache

Drawain · 2009. Szep. 29. (K), 23.58
Ezt még kiegészíteném azzal, hogy érdemes lecachelni a config fájlokat egy fájlba, ezután elég a cache-t üríteni ha valamit módosítunk, így mégis gyors marad a rendszer.
3

config file

Akron · 2009. Szep. 17. (Cs), 12.42
Vagy ha megváltozik a jelszó vagy db neve, akkor ki fog a kódban turkálni? A felhasználó? Vagy majd hív téged?
7

:-)

inf · 2009. Szep. 29. (K), 22.37
Igazad van.
4

Környezetek

zila · 2009. Szep. 18. (P), 07.59
Aztán ott van a DEV/TEST/PROD környezetek problémája, a te változatodban mindegyikre külön kódbázis kell, pedig a lényeg az, hogy ugyanaz a kód vándorol DEV->TEST->PROD irányban... Ugyanez config fájl esetén teljesül, a három környezetben csak a config különbözik, ami az adatbázis kapcsolatot írja le.

Az is előfordul, hogy nem csak az adatbázis kapcsolatot kell konfigurálni, hanem sok egyebet is (elérési utak, könyvtárak, formátumok, stb.), mindaz amit az ügyfélnek kell tudnia állítani.
8

Ok.

inf · 2009. Szep. 29. (K), 22.43
Értem.
Ami nálam nem tiszta még, hogy milyen formában érdemes tárolni az ilyesmit?

Én mondjuk arra gondoltam, hogy a config fájlt front-controllerrel inclucolom, és egy Config nevű osztály lesz benne, ami a különböző osztályoknak intézi az adatok átadását.
Valami ellenvetés? (pl: mindenki XMLt használ, etc..)
9

konfig fájl legyen

erenon · 2009. Szep. 29. (K), 22.51
A szerintem használható megoldás:
config fájl adott plain text-ben, (pl.: ini), ezt beolvassa egy osztály (ami dönt(het) az adatok formai helyességéről, valamint csak az adott környezetnek megfelelőt tartja meg(dev/test/prod)), aminek a felületén keresztül a többi kód hozzáfér a saját beállításaihoz.

Előnye, hogy a felhasználó könnyen tud változtatni, a kódok meg nem nyulkálnak a plaintextben.