[PHP] Config Opcje

[aras785]

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

array('mysql' => array('login'=>'test'))

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?

Ten post edytował !*! 25.02.2013, 20:17:04

[wujek2009]

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.

[Crozin]

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ę.

[Spawnm]

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ę.

[!*!]

Dlaczego korzystasz z metod/klasy statycznej, skoro możesz, i zapewne będziesz miał, wiele różnych plików konfiguracyjnych?

Jedno nie wyklucza drugiego.

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ę.

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

Ten post edytował !*! 26.02.2013, 09:16:14

[CuteOne]

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

[aras785]

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:

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ę.

Jak mam to inaczej rozwiązać?

[CuteOne]

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ć

Ten post edytował CuteOne 26.02.2013, 11:12:45

[pyro]

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.

Ten post edytował pyro 26.02.2013, 11:12:52

[CuteOne]

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

Ten post edytował CuteOne 26.02.2013, 11:19:57

[!*!]

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

[pyro]

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ś?

[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ł.

Ten post edytował pyro 26.02.2013, 11:26:57

[CuteOne]

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

[!*!]

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?

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.

[pyro]

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.

[Crozin]

Crozin, kolega ma problem z poprawnym napisaniem metody ładowania tablicy z pliku a ty mu każesz pisać sterowniki do ini/xml/yaml?

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".

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

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ą.

Zamierzam korzystać tylko z plików conf: *.php lub .ini . Nie chcę XML, YAML itd bo to mi do tego nie potrzebne.

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".

[CuteOne]

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

[!*!]

1. Poza nielicznymi przypadkami globalny dostęp do czegokolwiek jest raczej niepożądany.

Z powodu?

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ą.

Jakich problemów?

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

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

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

Ten post edytował !*! 26.02.2013, 12:31:30