Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> Dylematy co do konfiguracji w FW
menic
post 11.01.2007, 10:58:02
Post #1





Grupa: Zarejestrowani
Postów: 493
Pomógł: 0
Dołączył: 14.06.2003
Skąd: Tomaszów Lubelski/Rzeszów

Ostrzeżenie: (0%)
-----


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 winksmiley.jpg , 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 aarambo.gif


--------------------
Jak masz cos zrobic dobrze...
...To musisz zrobić to sam.

Uchwycić moment...
Go to the top of the page
+Quote Post
Cysiaczek
post 11.01.2007, 11:58:36
Post #2





Grupa: Moderatorzy
Postów: 4 465
Pomógł: 137
Dołączył: 26.03.2004
Skąd: Gorzów Wlkp.




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
  1. <?php
  2. //kontekst aplikacji
  3. $AHelper->getAppRegistry()->get("appName"); 
  4. $AHelper->getAppRegistry()->get("cacheStatus"); 
  5. $AHelper->getAppRegistry()->get("TEMPLATES", "paths"); // ścieżka do katalogu templates aplikacji
  6.  
  7. //kontekst modułu (mini-aplikacji np. system newsów)
  8. $AHelper->getModRegistry($moduleName)->get("name"); 
  9.  
  10. //Można oczywiście uprościć
  11. $appConfig=$AHelper->getAppRegistry();
  12. //i stosować
  13. $appConfig->get("appName");
  14. ?>


i jeszcze metoda application_Helper::getModRegistry(). Wprowadziłem kolekcję rejestrów (bo modułów jest przecież wiele)
  1. <?php
  2. public function getModRegistry($modName=false){
  3.  
  4. if ($modName==false){
  5. $modName=$this->getReqRegistry()->get('module');
  6. }
  7.  
  8. if (isset($this->moduleCollection)){
  9. return $this->moduleCollection->getModRegistry($modName);
  10. }
  11. else{
  12. $this->moduleCollection=module_registry_Collection::getInstance();
  13. $this->moduleCollection->addModRegistry(new module_Registry($modName), $modName);
  14. }
  15. }
  16. ?>


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.

Ten post edytował Cysiaczek 11.01.2007, 12:11:25


--------------------
To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness;
chaotic, confused, vulnerability, to inform yourself.
Think for yourself. Question authority.
Go to the top of the page
+Quote Post
sf
post 11.01.2007, 12:39:08
Post #3





Grupa: Zarejestrowani
Postów: 1 597
Pomógł: 30
Dołączył: 19.02.2003
Skąd: Tychy

Ostrzeżenie: (0%)
-----


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.


--------------------
Zapraszam na mój php blog, tworzenie stron.
Go to the top of the page
+Quote Post
marcin96
post 11.01.2007, 16:45:02
Post #4





Grupa: Zarejestrowani
Postów: 57
Pomógł: 0
Dołączył: 21.08.2003
Skąd: Będzin

Ostrzeżenie: (0%)
-----


Cytat
Na mysl przychodzi mi mysl aby konfiguracje trzymac w plikach .ini I tu nasuwa mi sie pytanie. Jak wydajne jest parse_ini() ?


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


--------------------
www.calek.info
Go to the top of the page
+Quote Post
cadavre
post 11.01.2007, 19:01:54
Post #5





Grupa: Zarejestrowani
Postów: 472
Pomógł: 7
Dołączył: 7.12.2005
Skąd: Gliwice

Ostrzeżenie: (0%)
-----


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.


--------------------
Silesian PHP User Group - www.spug.pl
Symfony2, OAuth2, budowanie API - masz pytania? Pisz!
Go to the top of the page
+Quote Post
menic
post 11.01.2007, 19:06:35
Post #6





Grupa: Zarejestrowani
Postów: 493
Pomógł: 0
Dołączył: 14.06.2003
Skąd: Tomaszów Lubelski/Rzeszów

Ostrzeżenie: (0%)
-----


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

Ten post edytował menic 11.01.2007, 19:08:13


--------------------
Jak masz cos zrobic dobrze...
...To musisz zrobić to sam.

Uchwycić moment...
Go to the top of the page
+Quote Post
splatch
post 12.01.2007, 09:21:50
Post #7





Grupa: Zarejestrowani
Postów: 487
Pomógł: 7
Dołączył: 7.01.2004
Skąd: Warszawa

Ostrzeżenie: (0%)
-----


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


--------------------
Łukasz Dywicki
Independent Java and open source software consultant.
Blog - Java, OSGi, integracja oprogramowania..
Go to the top of the page
+Quote Post
Turgon
post 12.01.2007, 11:11:21
Post #8





Grupa: Zarejestrowani
Postów: 800
Pomógł: 0
Dołączył: 26.11.2005
Skąd: Nowy Sącz

Ostrzeżenie: (0%)
-----


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 smile.gif Po prostu piszę nazwę zmiennej jako jej dokładny opis smile.gif :

  1. <?php
  2. /**
  3. Only to use in TurCMS or TurFramework.
  4. **/
  5. class TurConfig{
  6. private static $configurations = array();
  7.  
  8. public function __construct(){
  9. TurKernel::logMessage(get_class(),'Modul zostal uruchomiony.');
  10. }
  11.  
  12. public static final function get($confName){
  13. if(isset(self::$configurations[$confName])){
  14. TurKernel::logMessage(get_class(),'Pobrano klucz '.$confName.' z konfiguracji.');
  15. return self::$configurations[$confName];
  16. }
  17. }
  18. public static function getAll(){
  19. TurKernel::logMessage(get_class(),'Pobrano klucz wszystko z konfiguracji.');
  20. return self::$configurations;
  21. }
  22. public static final function load($confArray){
  23. self::$configurations = $confArray;
  24. TurKernel::logMessage(get_class(),'Klasa otrzymała tablicę konfiguracyjną.');
  25. return self::$configurations;
  26. }
  27.  
  28. public static final function loadFile($confPath){
  29. if(file_exists($confPath)){
  30. include_once($confPath);
  31. self::$configurations = $config;
  32. }
  33. TurKernel::logMessage(get_class(),'Klasa odczytała tablicę konfiguracyjną z pliku '.$confPath.'.');
  34. return self::$configurations;
  35. }
  36.  
  37. }
  38. ?>


--------------------
Jah Music Is On My Mind !
Go to the top of the page
+Quote Post
marcin96
post 14.01.2007, 16:47:41
Post #9





Grupa: Zarejestrowani
Postów: 57
Pomógł: 0
Dołączył: 21.08.2003
Skąd: Będzin

Ostrzeżenie: (0%)
-----


Cytat(cadavre @ 11.01.2007, 19:01:54 ) *
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.

Ż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 ;>)

Ten post edytował marcin96 14.01.2007, 16:48:11


--------------------
www.calek.info
Go to the top of the page
+Quote Post
cicik
post 15.01.2007, 19:37:15
Post #10





Grupa: Zarejestrowani
Postów: 219
Pomógł: 5
Dołączył: 18.07.2006
Skąd: Piekary Śląskie

Ostrzeżenie: (0%)
-----


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.


--------------------
CMS dla Twojej firmy
Wojciech Małota
Go to the top of the page
+Quote Post
Cysiaczek
post 15.01.2007, 23:51:26
Post #11





Grupa: Moderatorzy
Postów: 4 465
Pomógł: 137
Dołączył: 26.03.2004
Skąd: Gorzów Wlkp.




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

Pozdrawiam.


--------------------
To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness;
chaotic, confused, vulnerability, to inform yourself.
Think for yourself. Question authority.
Go to the top of the page
+Quote Post
cicik
post 16.01.2007, 06:36:11
Post #12





Grupa: Zarejestrowani
Postów: 219
Pomógł: 5
Dołączył: 18.07.2006
Skąd: Piekary Śląskie

Ostrzeżenie: (0%)
-----


Cytat(Cysiaczek @ 15.01.2007, 23:51:26 ) *
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?


--------------------
CMS dla Twojej firmy
Wojciech Małota
Go to the top of the page
+Quote Post
Cysiaczek
post 16.01.2007, 11:08:40
Post #13





Grupa: Moderatorzy
Postów: 4 465
Pomógł: 137
Dołączył: 26.03.2004
Skąd: Gorzów Wlkp.




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


--------------------
To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness;
chaotic, confused, vulnerability, to inform yourself.
Think for yourself. Question authority.
Go to the top of the page
+Quote Post
cicik
post 16.01.2007, 11:15:00
Post #14





Grupa: Zarejestrowani
Postów: 219
Pomógł: 5
Dołączył: 18.07.2006
Skąd: Piekary Śląskie

Ostrzeżenie: (0%)
-----


Cytat(Cysiaczek @ 16.01.2007, 11:08:40 ) *
@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


--------------------
CMS dla Twojej firmy
Wojciech Małota
Go to the top of the page
+Quote Post
Cysiaczek
post 16.01.2007, 11:30:20
Post #15





Grupa: Moderatorzy
Postów: 4 465
Pomógł: 137
Dołączył: 26.03.2004
Skąd: Gorzów Wlkp.




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.


--------------------
To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness;
chaotic, confused, vulnerability, to inform yourself.
Think for yourself. Question authority.
Go to the top of the page
+Quote Post
Ociu
post 16.01.2007, 13:58:14
Post #16





Grupa: Moderatorzy
Postów: 1 566
Pomógł: 37
Dołączył: 14.05.2003
Skąd: Kraków




Również stawiam na XML, ale nic nie przeszkadza, azby zrobić config dla wszystkich typów ( ini, xml, tablica, yaml etc. ).
Go to the top of the page
+Quote Post
Strzałek
post 16.01.2007, 21:07:38
Post #17





Grupa: Przyjaciele php.pl
Postów: 384
Pomógł: 6
Dołączył: 11.09.2004
Skąd: Grodzisk Mazowiecki

Ostrzeżenie: (0%)
-----


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


--------------------
Go to the top of the page
+Quote Post
menic
post 3.03.2007, 14:34:29
Post #18





Grupa: Zarejestrowani
Postów: 493
Pomógł: 0
Dołączył: 14.06.2003
Skąd: Tomaszów Lubelski/Rzeszów

Ostrzeżenie: (0%)
-----


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

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. smile.gif

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 ? smile.gif

Ten post edytował menic 6.03.2007, 22:36:46


--------------------
Jak masz cos zrobic dobrze...
...To musisz zrobić to sam.

Uchwycić moment...
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 28.03.2024 - 21:52