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 //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 public function getModRegistry($modName=false){ if ($modName==false){ $modName=$this->getReqRegistry()->get('module'); } if (http://www.php.net/isset($this->moduleCollection)){ return $this->moduleCollection->getModRegistry($modName); } else{ $this->moduleCollection=module_registry_Collection::getInstance(); $this->moduleCollection->addModRegistry(new module_Registry($modName), $modName); } } ?>
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.
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ś http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/ 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 /** Only to use in TurCMS or TurFramework. **/ class TurConfig{ private http://www.php.net/static $configurations = http://www.php.net/array(); public function __construct(){ TurKernel::logMessage(get_class(),'Modul zostal uruchomiony.'); } public http://www.php.net/static final function get($confName){ if(http://www.php.net/isset(self::$configurations[$confName])){ TurKernel::logMessage(get_class(),'Pobrano klucz '.$confName.' z konfiguracji.'); return self::$configurations[$confName]; } } public http://www.php.net/static function getAll(){ TurKernel::logMessage(get_class(),'Pobrano klucz wszystko z konfiguracji.'); return self::$configurations; } public http://www.php.net/static final function load($confArray){ self::$configurations = $confArray; TurKernel::logMessage(get_class(),'Klasa otrzymała tablicę konfiguracyjną.'); return self::$configurations; } public http://www.php.net/static final function loadFile($confPath){ if(http://www.php.net/file_exists($confPath)){ include_once($confPath); self::$configurations = $config; } TurKernel::logMessage(get_class(),'Klasa odczytała tablicę konfiguracyjną z pliku '.$confPath.'.'); return self::$configurations; } } ?>
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.
@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.
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 ?
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)