Witam. Jak według was powinno pobierać się konfuguracje z plik php? A może lepsze do tego jest file.ini ?

U mnie obecnie wygląda to tak:

[PHP] pobierz, plaintext 
<?php
namespace Lib;
 
class Config {
	public static $con;
	public static function get($var) {
		require('Config/config.php');
		self::$con = $config[$var];
		return(self::$con);
 
	}
}
[PHP] pobierz, plaintext 

I w pliku php:

[PHP] pobierz, plaintext 
$config['mysql'] = array (
'host'=>'localhost',
[..]
);
[..]
[PHP] pobierz, plaintext 

Przejrzyj CakePHP, mają niezłe rozwiązanie np odczytujesz wartości przez

[PHP] pobierz, plaintext 
Config:read('mysql.login');
[PHP] pobierz, plaintext 

Co odpowiada tablicy



Nie potrzebnie tworzysz zmienną $config.

file.php

[PHP] pobierz, plaintext 
return array();
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
require_once 'Config/file.php';
[PHP] pobierz, plaintext 

I co jak będę chciał wczytać inny plik?

Wraz z każdym wywołaniem "get' (czyli pobrania danej konfiguracji) wczytujesz plik konfiguracyjny (Config/config.php) zmień require na require_once.
Najlepiej moim zdaniem byłoby stworzenie funkcji "instance" lub "init" (jak kto woli) i w tej funkcji byłoby wczytywanie konfiguracji (tj: require_once + zapis do zmiennej publicznej $con)

a w funkcji statycznej "get" po prostu zastosować zapis:

[PHP] pobierz, plaintext 
public static function get($var, $default = NULL)
{
   return array_key_exists($var, self::$con) ? self::$con[$var] : $default;
}
[PHP] pobierz, plaintext 

Oczywiście funkcja instance/init musiałaby się uruchamiać wraz z aplikacja.

1. Nie powinieneś stosować sztywnego odczytu z INI/XML/YAML. Raczej powinieneś skorzystać ze "sterownika", który wczyta dane z dowolnego formatu.
2. Dlaczego korzystasz z metod/klasy statycznej, skoro możesz, i zapewne będziesz miał, wiele różnych plików konfiguracyjnych?
3. Odwoływanie się wewnątrz jednego obiektu, do jakiegoś globalnego Config::get('xxx') to paskudna praktyka, która prędzej czy później zemści się.

Crozin, kolega ma problem z poprawnym napisaniem metody ładowania tablicy z pliku a ty mu każesz pisać sterowniki do ini/xml/yaml?
Proponował bym aby aras najpierw pogrzebał w kodzie innych fw, i dopiero wtedy brał się za swój jeśli nadal będzie czuł taką potrzebę.

Jedno nie wyklucza drugiego.


W zasadzie to dlaczego? Globalny dostęp, jako singleton ma sens w przypadku plików konfiguracyjnych i jest dość przejrzysty.

!*! przyznał bym ci rację gdybyś zamienił "plików konfiguracyjnych" na "plik konfiguracyjny" - mała acz znacząca różnica.

Dzięki wszystkim za odpowiedzi. Zamierzam korzystać tylko z plików conf: *.php lub .ini . Nie chcę XML, YAML itd bo to mi do tego nie potrzebne. O co chodzi z tym:



Jak mam to inaczej rozwiązać?

Np. rejestrując obiekt(y) (google -> registry pattern php)

edit: ściągnij sobie Zenda 1.xx i zobacz jak wygląda wgrywanie konfigów a co ważniejsze w jaki sposób, możesz nimi zarządzać

Pewnie chodziło mu o coś w stylu:

[PHP] pobierz, plaintext 
class Blah {
 
public function something() {
 
Config::set('blah', 1);
 
}
 
}
[PHP] pobierz, plaintext 

Ale dlaczego to niby jest takie złe? Może często tego nie używam, ale jak już to zawsze znacznie ułatwiało niektóre sprawy zamiast je utrudniać, np. właśnie przy Config, Lang itp. Możliwe, że taki wzorzec projektowy ma już jakąś nazwę, ale sam go nazwałem Globalizator

// EDIT

Jakieś argumenty mile widziane.

Jasio wchodzi do sklepu aby kupić bułkę(main_config.ini), chleb(lang_config.ini) i 4l mleka(local_lang.ini), niestety w torbie(Singleton) Jasia jest miejsce tylko na jedną rzecz - co teraz pocznie biedny Jaś?

Użyje wzorca z mojego poprzedniego postu

Dlatego Config::get() powinien pobierać dane z tablicy, a Config::load() ładować zawarotść plików do tablicy głównej (patrz cakephp).

[PHP] pobierz, plaintext 
Config::load('main_config.ini', 'bulka');
Config::load('lang_config.ini', 'chleb');
Config::load('local_lang.ini', 'mleko');
 
// ...
 
echo Config::get('bulka.cena'); // 2 zł
echo Config::get('mleko.cena'); // Fatal Error: Allowed memory size of 8388608 bytes exhausted ...
[PHP] pobierz, plaintext 

// EDIT

@!*! mnie wyprzedził.

mysql.ini

[PHP] pobierz, plaintext 
resources.db.host = localhost
[PHP] pobierz, plaintext 

mssql.ini

[PHP] pobierz, plaintext 
resources.db.host = 10.1.1.1
[PHP] pobierz, plaintext 

W akcji add() użyję mysql.ini po czym odpalam akcję add2() gdzie używam mssql.ini, następnie odpalam akcję add3() gdzie ponownie używam mysql.ini - cio wtedy?


ps. nie znam CakePHP ale dla mnie (tak na logikę) ładowanie 10 plików do jednego obiektu to lekkie przegięcie

Nic, bo mysql.ini już siedzi w tablicy dodany przez Config::load() a skoro jest kilka mysql.ini to ścieżki się nie zgadzają i powinien być inny identyfikator.

To mozna zastosować rozwiązanie, ktore podałem powyżej i ładujesz tylko to co chcesz i w prosty sposób się do tego odwołujesz z dowolnego miejsca.

Przecież to się ogranicza do 1-2 interfejsów i dwóch obiektów współpracujących ze sobą. Takie coś kompletny nowicjusz powinien być wstanie zrobić po pierwszym lepszym "wprowadzeniu w OOP".
1. Poza nielicznymi przypadkami globalny dostęp do czegokolwiek jest raczej niepożądany.
2. Dostęp do konfiguracji przy pomocy singletona będzie niewiele czytelniejszy od zwykłego rozwiązania (IoC), a niesie za sobą standardowy zestaw problemów wynikających z tak ścisłego powiązania dwóch obiektów ze sobą.
Skoro już wiesz, że będziesz korzystać z PHP oraz INI skorzystanie z strategii jest w pełni uzasadnione. Szczególnie, zważywszy na fakt, że zapewne pliki INI będziesz chciał cache'ować.

Eydcja. A jak robisz zamieszanie z plikami to świadomie, poza tym nie widze problemu aby usunać inne mysql.ini Config::del('mysql') zaraz po wczytaniu z "globalnego zasięgu".

Przy rozbudowanej aplikacji takie zamieszanie raczej jest uzasadnione a usuwać i ponownie ładować te same dane zamiast użyć rejestru.. hmm mało optymalne

Z powodu?



Jakich problemów?

To jest raczej kwestia tego, co jest dla Nas wygodniejsze. Pierwszy sposób nie ma przewagi nad drugim i odwrotnie.


I tu się zgadzamy. choć nie wiem za bardzo, aby przytoczone tu rozwiązanie robiło burdel (chyba że jest źle napisane).

@!*!: Globalny dostęp/sningleton niesie za sobą pewną konstrukcję, a mianowicie:

[PHP] pobierz, plaintext 
public function doSth() {
  // jakaś tam metoda naszego obiektu
  $maxSth = Config::get('...max');
  // czy tam:
  $maxSth = Config::getInstance()->get('...max');
  // dalszy ciąg naszej metody
}
[PHP] pobierz, plaintext 

Taka konstrukcja tworzy relację pomiędzy naszym obiektem, a klasą Config. Bezpośrednią (tj. opartą o klasę, a nie implementację interfejsu) relację, która w dodatku jest ukryta (nagle w środku kodu jest jakieś odwołanie). No to teraz lista problemów:
1. Nasz obiekt, który może nie mieć kompletne żadnego związku z resztą systemu, nagle staje się niepotrzebnie uzależniony od klasy Config. Kodu nie da się łatwo odizolować - tracimy jego uniwersalność/przenośność.
2. Skoro dla naszego obiektu nie da się wytworzyć pożądanego środowiska (ponieważ sam obiekt je definiuje), tak prosta rzecz jak chociażby testy (niekoniecznie jednostkowe) stają się nagle bardzo trudnym zadaniem.
3. Zdecydowanie trudniej jest utworzyć dwa obiekty o różnej konfiguracji, ponieważ ta jest na sztywno zapisana w klasie Config. Konieczne byłyby potworki typu:

[PHP] pobierz, plaintext 
$...max = Config::get('...max');
$myObject = new MyObject();
Config::set('....max', 12);
$myAnotherObject = new MyObject();
Config::set('...max', $...max);
[PHP] pobierz, plaintext 

Albo rybki, albo akwarium. Jak piszesz coś co ma być publiczne, to raczej używasz czystego PHP lub jeśli jest dedykowane na jakiś FW to ichniejszych metod. To że są zależności to raczej normalne i trudno by było zbudować coś większego bez nich. Już nie wspominając że na "czysto" raczej się przez takie narzędzia danych nie ustala, a raczej przez parametry metody i nawet jakby Config::get/set() w niej istniał, to ustawienie parametru nie musi go wykonać.



To samo co wyżej. Jak potrzebujesz konfiguracji, trudno aby obiekty były gołe bez możliwości wgrania CFG z zewnątrz.

Dzięki. Czyli mam zrobić na zasadzie load, get...

Metoda load moze wygladac tak:

[PHP] pobierz, plaintext 
<?php
class Config {
	public static $configs=array();
	public static function load($file) {
		return self::$configs[] = parse_ini_file('Config/'.$file,true);
	}
 
}
[PHP] pobierz, plaintext 

Przepraszam za amatorkę w moich kodach ale staram się jak tylko potrafie

Jeśli już to:
self::$configs[$file] = parse_ini_file('Config/'.$file.'.ini',true);

Zależności są nieuniknione i same w sobie nie są absolutnie niczym złym. Chodzi o to by zależności były luźne, oparte na interfejsach, nie sztywne, pracujące na klasach. Pierwsze podejście ma właściwie same zalety, jest naturalne dla OOP - Google: IoC pros. Drugie powoduje masę problemów. Jedną, jedyną zaletą drugiego rozwiązania jest jego zwięzłość - przy małych czy "śmieciowych" projektach dobra architektura systemu zwyczajnie w świecie nie ma znaczenia.
Nie zrozumiałeś sensu podanego przeze mnie przykładu. Chodzi o problemy z ustawieniem zewnętrznego środowiska (tutaj konfiguracji) w przypadku ścisłych zależności, zresztą chyba wyższość jednego rozwiązania nad drugim jest widoczna przy bezpośrednim zestawieniu:

[PHP] pobierz, plaintext 
$config = new Config(...);
$someObject = new MyObject($config);
 
$modifiedConfig = new Config($config);
$modifiedConfig->set('...', '...');
$modifiedConfig->set('...2', '...2');
$anotherObject= new MyObject($modifiedConfig);
 
// powiedzmy, że metoda doSth pobiera coś z conifga, np. $config->get('default_value') gdy nie podamy żadnego argumentu.
$someObject->doSth();
$anotherObject->doSth();
 
// -----
 
$someObject = new MyObject(); // fajniej?
$anotherObject = new MyObject(); // co tutaj? Modifikacja globalnego Config? Jeszcze da się to zrobić (patrz: mój wcześniejszy post)
 
// tutaj jesteśmy już w tzw. ciężkiej dupie ;)
$someObject->doSth();
$anotherObject->doSth();
[PHP] pobierz, plaintext 

Jeżeli FW nie jest napisany w taki sposób, jak tutaj się sugeruje, to można mieć i rybki i akwarium niedużym/zerowym nakładem pracy.

ja bym raczej dał tak

[PHP] pobierz, plaintext 
public static function load($file) {
   if(!isset(self::$configs[$file]))
   {
      self::$configs[$file]= parse_ini_file('Config/'.$file,true);
   }
   return self::$configs[$file];
 
}
[PHP] pobierz, plaintext 

dzięki tamu unikasz wielokrotnego wczytywania i parsowania pliku

Crozin - przeczytałem, to wczoraj... czytam to dzisiaj, razem z linkami i nadal nie widzę wyższości jednego nad drugim o której piszesz.
Kwestia indywidualnego podejścia do projektowania samych bebechów, tudzież wygody.

Mam sobie tablice w pliku config:

[PHP] pobierz, plaintext 
<?php
return array(
			'mysql'=>array(
						'driver'=>'mysql',
						'host'=>'localhost',
						'dbname'=>'album',
						'login'=>'root',
						'password'=>'vertrigo'
						)
			);
[PHP] pobierz, plaintext 

I wczytuje go: Config::load('plik');

//funckja load:

[PHP] pobierz, plaintext 
public static function load($file) {
  		 if(!isset(self::$configs[$file]))
   			{
      			self::$configs[$file]= include_once('Config/'.$file.'.php');
   			}
   		return self::$configs[$file];
	}
[PHP] pobierz, plaintext 

I jak zrobić aby za pomocą get pobiera dowolny ciąg czyli:

[PHP] pobierz, plaintext 
Config::get('plik.mysql.host'); //wyswietli localhost
[PHP] pobierz, plaintext 

Lub

[PHP] pobierz, plaintext 
Config::get('plik.mysql');  //wyswietli tablice
[PHP] pobierz, plaintext 

Wiem, ze trzeba podzielić argument który podajemy funkcji get funckją explode, a później jak to dynamicznie obrobić? Bo łatwo jest sobie zrobc return self::$cos[$explode[0]][$explode[1]][$explode[2]]; //to dla pierwszego przykladu.

Proszę o jakieś pomysły bo póki co korzystam z parse ini ale to siedzi cały czas w mojej głowie... Pozdrawiam

Ktoś da jakąś wskazówkę?

Kiedyś napisałem coś takiego:

[PHP] pobierz, plaintext 
   public static function get($name = null)
    {
        if(null === $name)
        {
            return self::$configs;
        }
 
        $name = trim($name, '.');
 
        if(isset(self::$configs[$name]))
        {
            return self::$configs[$name];
        }
 
        $cfg = &self::$configs;
 
        foreach(explode('.', $name) as $key)
        {
            if(isset($cfg[$key]))
            {
                $cfg = &$cfg[$key];
            }
            else
            {
                return null;
            }
        }
        return $cfg;
    }
[PHP] pobierz, plaintext 

Zresztą, wspomniałem już żebyś się zapoznał z cakePHP, mechanizm jest bliźniaczy.

wiem że bardzo "statycznie" ale to tylko pokazówka

[PHP] pobierz, plaintext 
class conf{
 
	public static $configs;
	public static function path($array, $path, $default = NULL, $delimiter = NULL)
	{		
		do
		{
			$key = array_shift($path);		
			if (isset($array[$key]))
			{
				if (!empty($path))
				{
					if (is_array($array[$key]))
					{
						$array = $array[$key];
					}
					else
					{
						break;
					}
				}
				else
				{
					return $array[$key];
				}
			}
			else
			{					
				break;
			}
 
 
		}
		while (!empty($path));		
		return $default;
	}
	public static function load($group)
	{
 
 
		$path = explode('.', $group);
		return conf::path(self::$configs, $path, NULL, '.');
 
 
 
	}
}
conf::$configs=array('x'=>array('y'=>array('z'=>155)));
var_dump(conf::load('x.y.z'));
[PHP] pobierz, plaintext 

Nie, to nie kwestia indywidualnego podejścia. To kwestia pewnych standardów, wypracowanych reguł w inżynierii oprogramowania. Za @Crozinem - oczywiście jeżeli robisz małe projekty to nie uświadczysz większej różnicy. Ale czemu od początku nie robić tego dobrze?

Polecam: (w tym przypadku najlepiej od slajdu 6)
http://www.slideshare.net/fabpot/dependenc...ion-in-php-5354

W tym przypadku słowo "standard" to lekkie nadużycie.
Dobra prezentacja, o to właśnie mi chodziło, aby np. Klasa User miała sama w sobie możliwość ustalenia konfiguracji, ale ni jak ma to się do samej klasy odczytu CFG.