Witam,
ostatnio zainteresowała mnie teoria działania systemów typu CMS jak fora dyskusyjne, czy aplikacje ułatwiające tworzenie stron poprzez wpisywanie treści w wygodnych dla użytkownika interfejsach.
CMSy mają mnogość konfigurowania, dzięki temu są tak wygodne i można je łatwo dostosować do swoich potrzeb. Jeżeli cała konfiguracja opiera się na jednym pliku, to jak taki plik przygotować?
Interesuje mnie możliwość sprawnego odczytu, jak i zapisu przez aplikację, a nie developera/użytkownika.
Który format pliku byłby najlepszy i jakich funkcji użyć? Nabieram wprawy w PHP, jeżeli będzie konieczność napisania klasy zajmującej się takim plikiem, nie będę miał z tym problemów.

Moim zdaniem to w plikach konfiguracyjnych trzymasz dane, które pozwolą nawiązać połączenie z bazą danych a reszta w bazie. (łatwa edycja)

Trzymać konfigurację w SQLite? [;

Tak jak mój poprzednik - potwierdzam SQLite, ale możesz również rozważyć pliki XML.
Opcja z trzymaniem danych do bazy w pliku .php a resztę konfiguracji w bazie, to też dobra rzecz.

Witam!

Zależy od aplikacji. Czasami wystarczy zwykły .ini lub .csv Jednak nie jest to w ogóle skalowalne i chyba lepiej korzystać od razu z xml'a. Jednak jak masz jakiś wrapper to w sumie bez różnicy w czym trzymasz. Jak komu wygodnie i wg potrzeb...

Niektórzy definiują tablicę w includowanym pliku po prostu.

[PHP] pobierz, plaintext 
<?php
//plik, który zostanie zaincludowany
$database_configuration['user'] = "AdamMickiewicz";
$database_configuration['pass'] = "1828";
 
//myk omijający globale 
return $database_configuration;
?>
[PHP] pobierz, plaintext 

Pozdrawiam!

Najlepiej by było gdyby konfiguracja nie była zależna od jakiegoś konkretnego formatu. Możesz stworzyć sobie n klas implementujących taki sam interface, a operujących na innych formatach danych, np.:

[PHP] pobierz, plaintext 
<?
$config = new IniConfig();
$conifg = new XMLConfig();
$config = new SqliteConfig();
$config = new YAMLConfig();
$config = new PHPConfig();
 
$config->open('/path/to/file');
$config->read('my var');
$config->save();
$config->whatever();
?>
[PHP] pobierz, plaintext 

Koniec końców i tak najlepiej, jakby konfiguracja była cacheowana do pliku, gdzie dane byłby w postaci zserializowanej tablicy czy obiektu - bo to jest odczytywane najszybciej.

Dobrą alternatywą dla XMLa jest JSON

Hm... na JavaScriptcie za bardzo się nie znam... tyle tylko co podstawy. W końcu będzie się trzeba nauczyć, ale na razie...

• MySQL jest niezłym rozwiązaniem, wystarczy napisać klasę potomną od zarządzającej tabelami...
• SQLite podoba mi się, ale jak czytałem ma wiele wad, a poza tym mało darmowych serwisów hostingowych obsługuje to rozszerzenie.
• XML nie wiem czemu, ale też mi się podoba . Nie wiem tylko, czy jest jakaś funkcja zamieniająca taki plik na drzewiastą tablicę, coś jak parse_ini_file" title="Zobacz w manualu PHP" target="_manual

Zastanawiam się nad MySQL albo XML, chociaż nie wiem jak by można edytować taki plik.

Jesli chodzi o XMl to masz chyba simpleXML do parsowania danych w plikach xml jesli dobrze pamietam.

Jak nie to mozesz napisac prosta klase specjalnie dla twoich plikow konfiguracyjnych.

SimpleXml Ci to bardzo ładnie załatwi, a dokładniej rzecz biorąc funkcja simplexml_load_file

jeśli odpowiednio dobrze przemyślisz konfigurację, to w takim wypadku pobranie całej zamyka się w użyciu wyżej wymienionej funkcji. Klasa pozwala też na edycję konfiguracji np z poziomu panelu Administratora.
(jeśli dobrze pamiętam to wystarczy zmienić wartość w naszej array i plik zapisać funkcją SimpleXMLElement::asXML)

Ja tam wolę .ini - nie trzeba zaprzęgać całego parsera DOM jak w przypadku xml. A co do odczytu/zapisu? Zend_Config przykładowo.


Raczej większość obsługuje. Nawet czasami zdarzają się hostingi gdzie to jedyne rozszerzenie dla PDO. Jest kilka razy szybszy niż typowy system bazodanowy.

odnośnie ini - jest fajna funkcja przetwarzająca ten plik na tablicę - parse_ini_file()

Przypominam że należy, nie ważne czy plik xml czy ini, odpowiednio zabezpieczyć przed odczytaniem przez osoby do tego niepowołane. Z plikiem php nie ma tego problemu.

W sumie tez wole pliki *.php niz *.ini ktore poprzednio uzywalem bo trzeba bylo dawac jakies *.htaccess by nie mozna bylo podgladac pliku a w php jest fajny myk dajemy wszystko jako komentarz /*config*/ i gitara gra

A co ci broni zapisać ini jako .php?



Poza tym takie pliki to się trzyma poza public_html.

Polecam interfejs niezależny od formatu i konkretne implementacje, które będą ładować poszczególne jej fragmenty z różnych źródeł. Jakich... hmmm... nie sprecyzowałeś, czym wg Ciebie ma być "najlepszy" format. XML, pliki INI, PHP, baza... przechowasz w nich z grubsza to samo. Może w nieco inny sposób będą opisane niektóre elementy, ale wszędzie da się je zachować.

Wybór może być uzależniony od niezbędnej funkcjonalności. Przykładowo, haseł i konfiguracji dostępu do bazy danych raczej nie zmienia się codziennie, więc spokojnie można je trzymać nawet w skrypcie PHP, byleby nie było to zbyt mocno zagrzebane. Jeśli natomiast ma istnieć możliwość personalizacji niektórych ustawień, albo ich edycji po stronie WWW, baza danych byłaby także dobrym wyborem.

Kiedyś robiłem benchmark różnych formatów danych (plikowych). Może Ci to nieco pomóc w wyborze, jeśli potrzebujesz informacji o wydajności (w końcu podstawowa konfiguracja musi być ładowana w każdym żądaniu):

Formaty danych: benchmark cz. 1
Formaty danych: benchmark cz. 2

A po co się za każdym razem łączyć?


Wady ma przy stosowaniu jako podstawowa baza przy dużej ilości zapisów. Przy odczycie często nie ma sobie równych. A argument, że wiele darmowych hostingów nie obsługuje, to możesz wcisnąć między drzwi a futrynę. Szukasz innego hostingu, konkurencja jest.


No jest, ale parsowanie XML jest chyba najwolniejszym rozwiązaniem, gdyż parser musi najpierw go zwalidować, dopiero potem obrabia. Strzał do muchy z armaty - skoro konfiguracja nie będzie migrowała między różnymi środowiskami oprogramowania, to jest to rozwiązanie co najmniej bez sensu.

Jest jeszcze YAML, ale dla mnie to próba wrzucenia czegoś na siłę.

Gdzieś kiedyś czytałem, że najlepszym wyjściem jest zserializowana tablica (nawet szybsza niż kod PHP do parsowania), ale to rozwiązanie dalekie od wygody.

Choć jeśli chodzi o np. czysty kod PHP, to najlepiej się chyba do edycji nadaje, gdyż wystarczy użyć var_export" title="Zobacz w manualu PHP" target="_manual i z głowy. Wada - nie zachowa nazw stałych...

Albo czasem połączenie zserializowanej tablicy z bazą danych, jak to robi Wordpress (trzyma zserializowane ustawienia dla przykładu wtyczek, w bazie).

YAML - zgadzam się w 100%, wrzucanie czegoś na siłę.

~dotangelo, tylko Wordpress tego potem nie porządkuje i zostaje bałagan w bazie.

W porządku, ale jak później wnikać w plik php i edytować go (pamiętasz, potrzebna jest mi także możliwość swobodnego zapisu/edycji). Czy dałoby się to zrobić tak jak edytowanie pliku? Jeśli tak to nie ma problemu ze stałymi, bo mogę zastosować wzorzec własności/rejestru (property/registry). One czymś się w ogóle różnią? Po prostu chodzi mi o sprawną możliwość zapisu/odczytu.

Co zatem proponujesz? Wzorzec obserwatora + plik który by przechowywał dane z bazy i byłby odświeżany przy zmianach?
BTW.: Moje proste pytanie rozwinęło się w interesującą dyskusję. Może by tak podwiesić?

Pozwolę sobie podlinkować do mojego wcześniejszego postu: http://forum.php.pl/index.php?s=&showt...st&p=639445
Wybierz sobie dowolny format, który będzie Ci pozwalał na wygodną modyfikację.

Dane będziesz i tak raz odczytywał i zapisywał do cachea w postaci zserializowanych danych - bo one są najszybsze w odczycie.
Po edycji danych będziesz wywalał plik cachea, co wymusi jego ponowne utworzenie.

Napisałem - edytujesz jak normalną tablicę, potem var_export" title="Zobacz w manualu PHP" target="_manual i wypluwasz to do pliku. ;]

Oj przepraszam, przeoczyłem to . A jak później takie coś "złożyć" w jakiś plik konfiguracyjny? Bo format danych tej funkcji za bardzo nie przypomina ani XMLa, ani INIa ani innych plików konfiguracyjnych. Sam muszę napisać przerabiarkę czy jest jakaś funkcja?

Nie, jest to bardzo łopatologiczne:

Wybacz erix, ale nie rozumiem. Zainteresowany var_exportem() postanowiłem sam zrobić jakiś przykład. Mam wyplute coś takiego:

I jak to przerobić na plik INI albo "zserializowaną tablicę" w PHP? Mógłbyś podać gotowca, jest już późno, mózg już usypia

Ale nie rozumiesz ;p
Przecież to jest prawidłowa tablica dla kodu PHP, którą wystarczy zainclude" title="Zobacz w manualu PHP" target="_manual'ować do aplikacji. [;

hm... fucktycznie nie rozumiem. W manualu ta funkcja wygląda tak samo jak print_r, czy var_dump (w sensie że wyświetla drzewo tablicy). Używam takich funkcji do obejrzenia sobie czasem tablic, ale nie rozumiem, jak wypluty tekst można zainkludować. Czy mógłbyś mi podać przykład, jak to wszystko zrobić. Naprawdę przepraszam, ale jakoś nie zrozumiałem.

var_export() to nie to samo co print_r" title="Zobacz w manualu PHP" target="_manual

[PHP] pobierz, plaintext 
<?php
$myArray = array(
  'key1' => 'value',
  'key2' => 321,
  'key3' => array(
    'subkey' => 'my val'
  )
);
 
echo var_export($myArray);
?>
[PHP] pobierz, plaintext 

Zauważyłeś, że to wyświetla poprawny kod PHP? To teraz jakbyś zamiast echo dał tam:

[PHP] pobierz, plaintext 
file_put_content('<?php $myArray =  . var_export(...))
?>
[PHP] pobierz, plaintext 

To by utworzyło Ci poprawny plik PHP.

O-żesz-ku... nie wpadło mi to do głowy! Teraz tylko muszę napisać klasę obsługującą to wszystko razem. Wielkie dzięki.