Pisze własnego Fw na osobiste potrzeby, ale może kiedyś udostepnie go, ale mniejsza z tym. Zastanawiam sie jak rozwiązać konfiguracje w FW. Ogólnie pisząc dosyć mocno wzoruje sie na Symfony. Tak więc jeśli chodzi o podział konfiguracji:
-stałe "globalne" z sciezkami, rozszerzeniem plikow .class, defaultowa akcja itp.
-----
-konfiguracja samego FW
-konfiguracja aplikacji
-konfiguracja modułów
-----
I nie wiem jak najlepiej to rozwiązać. Na mysl przychodzi mi mysl aby konfiguracje trzymac w plikach .ini I tu nasuwa mi sie pytanie. Jak wydajne jest parse_ini() ? Czy może konfiguracje z .ini parsować do .php czy raczej nie ma sensu? Pliki .ini są stosunkowo łatwe w edycji. Ewwntualnie można użyć yaml , ale to już drugorzędna kwestia. I jak teraz tu rozdzielić dostep do konfiguracji? Czy zrobić podział na np. getModuleConfig(var), getConfig(var) itp. czy np. getConfig(var, module='') Jesli przekazany zostanie jeden parametr to pobierana jest konfiguracja aplikacji/fw, a przeciwnym wypadku pobieramy konfiguracje modułu podanego jako drugi parametr.
Co wy o tym sądzicie? Chętnie poczytam jak wy rozwiązujecie tą kwestie. Wszystkie pomysły oraz wskazówki mile widziane

Już gdzieś pisałem, ale co tam : P
Mam po prostu coś na kształt rejestru.
Parę prościutkich przykładów. Korzystam z obiektu bramy o nazwie application_Helper

[PHP] pobierz, plaintext 
<?php
//kontekst aplikacji
$AHelper->getAppRegistry()->get("appName"); 
$AHelper->getAppRegistry()->get("cacheStatus"); 
$AHelper->getAppRegistry()->get("TEMPLATES", "paths"); // ścieżka do katalogu templates aplikacji
 
//kontekst modułu (mini-aplikacji np. system newsów)
$AHelper->getModRegistry($moduleName)->get("name"); 
 
//Można oczywiście uprościć
$appConfig=$AHelper->getAppRegistry();
//i stosować
$appConfig->get("appName");
?>
[PHP] pobierz, plaintext 

i jeszcze metoda application_Helper::getModRegistry(). Wprowadziłem kolekcję rejestrów (bo modułów jest przecież wiele)

[PHP] pobierz, plaintext 
<?php
public function getModRegistry($modName=false){
 
	if ($modName==false){
	$modName=$this->getReqRegistry()->get('module');
	}
 
	if (isset($this->moduleCollection)){
	return $this->moduleCollection->getModRegistry($modName);
	}
	else{
	$this->moduleCollection=module_registry_Collection::getInstance();
	$this->moduleCollection->addModRegistry(new module_Registry($modName), $modName);
	}
}
?>
[PHP] pobierz, plaintext 

Mniej więcej tak to wygląda. Mam jeszcze rejestry dla żądania (requestRegistry), sesji (sessionRegistry), ale w chwili obecnej są w fazie rozwoju i nie wiem, czy nie zmienię ich na coś innego. Nie używam natomiast globalnych stałych, choć kiedyś używałem.
Konfigurację trzymam w stringach XML, ale część (np ścieżki do katalogów) w gotowych tablicach
Polecam zatem jawne oddzielenie konfiguracji modułów od konfiguracji aplikacji.

Pozdrawiam.

Parsowanie pliku ini nie wydaje mi się, aby zajmowało dużo czasu. W sumie tak miałem dotchczas to zrealizowane. Obecnie przerobiłem to na xml. Co do parsowania do pliku php to jak najbardziej tak, ale jest to kwestia na dalszy etap pracy gdy opracujesz już klase cache, aktualnie nie jest to takie istotne.

Zupełnie nie ma sensu.. wręcz nawet lepiej jest trzymać w ini niż... w zmiennych php includowanych. Zrób sobie test prosty: inlcuduj 100 razy plik php przypisujący wartości do zmiennych i parsuj 100 razy plik .ini, który zwróci takie same zmienne. Pliki ini są prostsze w interpretacji niż php i stąd (podejrzewam) różnica w czasie na korzyść .ini

INI vs. XML - lepiej wypada XML (benchmarki i jakość zapisu)

Jednak tak parse_ini jak i simplexml (zakładam) są rozwiązaniami wolnymi. U siebie stosuję własny parser XML'a.

Jakoś mi sie nie chce wierzyć ze XML wypada lepiej wydajnościowo od ini.
Biorąc do kupy to wychodzi xml<ini<php Czyli xml jest szybszy od tablic php. Dla mnie jakaś paranoja...

XML daje znacznie więcej możliwości, napisałem kiedyś kilka słów na ten temat

Powiem to tak. U mnie TurCMS (Jest tak rozbudowany że zaczyna przypominać FW) tworzy sobie podczas instalacji Obraz. Pierwsze co następuje po uruchomieniu Kernela jest odpalenie klasy TurConfig i załadowanie tego obrazu. Ja się nie bawię w jakieś tam rozdziały Po prostu piszę nazwę zmiennej jako jej dokładny opis :

[PHP] pobierz, plaintext 
<?php
/**
Only to use in TurCMS or TurFramework.
**/
class TurConfig{
private static $configurations = array();
 
public function __construct(){
TurKernel::logMessage(get_class(),'Modul zostal uruchomiony.');
}
 
public static final function get($confName){
if(isset(self::$configurations[$confName])){
TurKernel::logMessage(get_class(),'Pobrano klucz '.$confName.' z konfiguracji.');
return self::$configurations[$confName];
}
}
public static function getAll(){
TurKernel::logMessage(get_class(),'Pobrano klucz wszystko z konfiguracji.');
return self::$configurations;
}
public static final function load($confArray){
self::$configurations = $confArray;
TurKernel::logMessage(get_class(),'Klasa otrzymała tablicę konfiguracyjną.');
return self::$configurations;
}
 
public static final function loadFile($confPath){
if(file_exists($confPath)){
include_once($confPath);
self::$configurations = $config;
}
TurKernel::logMessage(get_class(),'Klasa odczytała tablicę konfiguracyjną z pliku '.$confPath.'.');
return self::$configurations;
}
 
}
?>
[PHP] pobierz, plaintext 

Że co? parse_ini jest wolne? ;>) Można informacje o jakie benchmarki chodzi?

Jeśli chodzi o 'jakość zapisu' - to nas nie interesuje, bo omawiamy konfiguracje wpisywaną z palca, zatem zależy nam na jak najszybszym odczycie.

Oczywiście XML/czysty php są znacznie bardziej skalowalne - w .ini zapisać można jedynie tablicę dwuwymiarową, lecz w wielu wypadkach to zupełnie wystarczy.

Pozdrawiam ;>)

Ja robiłem testy ale ich wyników nie podam bo nie pamiętam.
Robione były na php 5.1.x więc w miarę aktualne.
W testach brałem trzy możliwości:

- dwuwymiarowa tablica zapisana w php
- plik ini
- deserializacja wcześniej zserializowanej tablicy dwuwymiarowej

Rozwiązanie trzecie działało najszybciej ( i tego używam), rozwiązanie pierwsze - najwolniej.
Nie próbowałem na plikach XML ale biorąc pod uwagę, że stosunkowo duży odsetek czasu generowania strony zajmuje parsowanie plików językowych w standardzie TMX to rozwiązanie xmlowe wydaje mi się najwolniejsze.

Z drugiej strony pliki XML bosko się cache'ują, więc problem szybkości odpada : D

Pozdrawiam.

Skoro chcesz je cachowac to po co Ci one?
Nie lepiej je od razu trzymac w postaci scachowanej?

@cicik - nie, jeśli chcesz mieć możliwość łatwej zmiany konfiguracji, a nawet posiadasz aplikację, która umożliwia zarządzanie danymi w tych plikach. Cache to raczej w tym wypadku coś a'la kompilacja.

Pozdrawiam.

No to mozna zrobic albo formularz albo skrypcik, ktory skompiluje

Może napiszę szerzej : )

Załóżmy, że masz 10 plików XML o ustalonej strukturze i musisz je parsować (niekoniecznie wszystkie naraz). Problemem jest to, że jeden plik może odnosić się do informacji innego pliku, ten z kolei do jeszcze innych trzech plików. Taka operacja jest czasochłonna, a wystarczy, aby parser, wynik działania umieścił w tablicy. Tablica jest cache'owana i nie ma problemu. Zachowujemy ładną formę plików XML i łatwość edycji.
Pozostaje jeszcze kwestia zarządzania tymi relacjami w wielu plikach - ręcznie to masakra i nie polecam nikomu. Przy odrobinie wysiłku można jednak napisać aplikację www, która będzie czytała te pliki, sprawdzała relacje, sama aktualizowała wymagane elementy itd. itp.

Owszem, można to zrobić na INI, ale po co, jeśli XML daje większe możliwości?

Pozdrawiam.

Również stawiam na XML, ale nic nie przeszkadza, azby zrobić config dla wszystkich typów ( ini, xml, tablica, yaml etc. ).

Zaczynałem na stałych, później tablice, następnie ini, by skończyć na xml.

Uważam to za najlepsze rozwiązanie, które sam stosuje. Przede wszystkim xml daje mi dużoooo większe możliwości.
Parsuje plik, robie cache i jazda.

Może nawet notkę dla początkujących na blogu napiszę

Problem, przechowywania konfiguracji jest zalatwiony. Ale głownym tematem dyskusji jest logiczny podział konfiguracji Tzn jak sie odwolywac do poszczegolnych jej czescj jak konfiguracja FW, aplikacji oraz modulu

Mam taki dylemat. Czy widok powinien miec dostep jakos do konfiguracji czy nie? Wg mnie nie, ale czasem wygodniej jets jak ma. Tak wiec czy pozwolic widokowi na odczytywanie konfiguracji czy zamiast w tego w akcji deklarujemy jakie wartosci konfiguracji beda potrzebne widokowi i je przesyłamy?
EDITED
Juz wybrałem. Widok dostaje to co zadeklarujemy dla niego w akcji + wartości systemowe, takie jak nazwa aktualnej akcji itp.

No ale mam jeszcze jeden maly dylemat. Czy konfiguracje pobierac za pomoca $this->getConfig('var') czy tez moze przez $this->config->var ? Jakie jest wasze zdanie ?