Dylematy co do konfiguracji w FW |
Dylematy co do konfiguracji w FW |
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 , 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 -------------------- |
|
|
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
i jeszcze metoda application_Helper::getModRegistry(). Wprowadziłem kolekcję rejestrów (bo modułów jest przecież wiele)
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. |
|
|
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.
|
|
|
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
|
|
|
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! |
|
|
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.
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 -------------------- |
|
|
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.. |
|
|
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 Po prostu piszę nazwę zmiennej jako jej dokładny opis :
-------------------- Jah Music Is On My Mind !
|
|
|
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%) |
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
|
|
|
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 |
|
|
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. |
|
|
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%) |
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 |
|
|
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. |
|
|
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%) |
@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 |
|
|
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. |
|
|
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. ).
|
|
|
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ę -------------------- |
|
|
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 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 ? Ten post edytował menic 6.03.2007, 22:36:46 -------------------- |
|
|
Wersja Lo-Fi | Aktualny czas: 23.09.2024 - 04:41 |